Почему запросы PUT и DELETE в наше время почти умерли?

Что подразумевается под нашем временем? И когда это они жили полноценной жизнью?

В рестовых апи они кстати совсем не редки. Ну и PUT не нужен, PATCH наше всё.

Не понял, что мешает ими пользоваться? Я всегда делаю PUT и DELETE если в этом есть смысл

Потому что не нужны?

Использую каждый день PUT, PATCH, DELETE с Rails+Backbone.js

А у кого умерли-то? У говнокодеров? Так у них никогда ничего правильно и не делалось))

+1

Если они используются в API редко, то это только потому, что доморощенные API-десигнеры привыкли всё делать через ж POST, даже операции чтения без побочных эффектов. А вообще, например, CRUD-операции интуитивно мапятся на POST, GET, PUT и DELETE соответственно, и гайды по REST-дизайну так и рекомендуют делать.

Потому что рестовые апи не нужны.

Потому что браузер не поддерживает методы, отличные от GET/POST.

Это что за браузер такой?

А зачем они? Даже в апи запросы на чтение данных - это GET, запросы модифицирующие данные - POST. Какая разница что делать, delete /entity/id или post /entity/delete/id

4.2 же. Даже IE6 поддерживает PUT и DELETE через XHR. IE < 9 не поддерживает их только в HTML-формах.

Любой. В формах они вроде все не поддерживают.

Естественно речь про формы.

А зачем отправлять PUT и DELETE через формы?

А зачем отправлять PUT и DELETE через формы?

Загрузка файлов? Удаление сообщения?

Странный вопрос. Надо мне отправлять данные на сервер. Зачем мне это делать аяксом, наворачивая кучу ненужного кода, если это можно сделать формой? Я вообще считаю, что 99% сайтов должны работать без JavaScript (JavaScript, незначительно повышающий удобство использования допустим, но не должен блокировать функционал). Поэтому если сервер принимает такие глаголы, то это автоматически отсекает часть возможного функционала на клиенте. Зачем это надо? Про костыли вроде посылки доп.параметрам _method я знаю, но это костыли, которые проще сразу выкинуть и использовать GET/POST.

Вот почему браузеры поддерживают только два глагола - это вопрос интересный. Если бы поддерживали весь спектр - я бы с удовольствием их использовал.

Я вообще считаю, что 99% сайтов должны работать без JavaScript (JavaScript, незначительно повышающий удобство использования допустим, но не должен блокировать функционал).

Я тоже так думал, а потом устроился на работу.

Сочувствую.

лишь в API

лишь

Где нужно, там и используются.

С чего бы это? Используется и то и то. Естественно в API и дергается через js в браузере.

Да потому что если юзать его даже как апи, то хренова синхронность убивает всё и вся. А если начинать колдовать асинхронность, то нахрен не нужно это ваше путоделето, хватит и поста с лонгами пулингами, кометами и прочим мозгошевелением. Да, теоретически с помощью этого самого реста получается всё так чётко, красиво и увлекательно, но как-то плохо ложиться на реальную жизнь. То ли быдлокодинг, он конечно же, то ли хттп всё таки говно.

Зачем мне это делать аяксом, наворачивая кучу ненужного кода, если это можно сделать формой?

Затем что если ты сделаешь это формой, тебе нужно будет заново загрузить страницу после обработки. А если аяксом, достаточно загрузить ответ (в некоторых случаях только статус ok или error) и обработать его на стороне клиента.

Затем что если ты сделаешь это формой, тебе нужно будет заново загрузить страницу после обработки.

Вот и здорово. Удобная модель программирования, привычный пользователю user experience, не требует JavaScript, friendly к поисковикам.

А если аяксом, достаточно загрузить ответ (в некоторых случаях только статус ok или error) и обработать его на стороне клиента.

Это уже не сайт, а потуга на приложение. В большинстве случаев это не нужно.

Вот и здорово.

Обладатели слоуинтернетов смотрят на тебя с ненавистью.

Удобная модель программирования

Для тех, кто не осилил MVC-фреймворки.

привычный пользователю user experience

Зависит от возраста пользователя.

friendly к поисковикам

Нормальные поисковики уже давно научились по аяксосайтам ходить.

В большинстве случаев это не нужно.

Ну да, сравни, сколько трафика занимает ответ и сколько - целая страница. Плюс серверу ещё нужно пыхтеть и генерировать эту страницу.

привычный пользователю user experience

4.2

не требует JavaScript

Не имеет значения, он давно уже везде есть.

friendly к поисковикам

Поисковики делают post?

Поисковики делают вдоль

Обладатели слоуинтернетов смотрят на тебя с ненавистью.

Обладатели слоу и анстейбл интернетов смотрят с ненавистью на кучу JS'ов, которые тестировались только на локалхосте и которые непременно отваливаются и начинают глючить при краткосрочном отключении интернета / плохом соединении.

На нормальных сайтах все действия можно повторить. Если нет - разрабы криворуки и голый HTML их не спасёт.

Что значит «умерли»? Сплошь и рядом везде же.

Ни разу не встречал запроса DELETE. Года за три в логах сквида болтались лишь PUT, GET да POST. Чаще, понятное дело, GET; на втором месте POST и примерно так же, как POST относится к GET'у, к POST'у относится PUT.

Затем что если ты сделаешь это формой, тебе нужно будет заново загрузить страницу после обработки.

4.2!!! Тупо результат выводишь в скрытый iframe! Я так когда-то давно делал, пока XHR не осилил. Скрытыми фреймами, кстати, до сих пор пользуюсь: та же "ЛОР-панель" использует скрытый фрейм для подгрузки дополнительной страницы.

Потому что школоло, которые из всего REST запомнили только про глаголы, не пускают к проектированию API.

В случае RESTful-подхода интерфейс описывается аббревиатурой CRUD - Create, Read, Update, Delete. При использовании в качестве транспорта HTTP данные операции отображаются на методы данного протокола: POST, GET, PUT, DELETE, соответственно. Сущности, над которыми выполняются данные операции, однозначно идентифицируются с помощью Uniform Resource Identifiers (URI). Всё.

Только DELETE фактически никому нафиг не нужен!

DELETE нужен для удаления записи в таблице БД через объект персистентности JPA, например.