Какая польза от методов HTTP-запроса PUT и DELETE?

Я много читал об этом, но не могу сделать вывод по этой теме.

Но я никогда не использовал методы HTTP-запроса PUT или DELETE. Моя тенденция - использовать GET, когда статистика системы (мое приложение или веб-сайт) не может быть затронута (например, список продуктов), и использовать POST, когда это влияет (размещен заказ). Этого недостаточно или я что-то упускаю?

DELETE предназначен для удаления ресурса запроса:

Метод DELETE требует, чтобы исходный сервер удалил ресурс, указанный в Request-URI. Этот метод МОЖЕТ быть переопределен вмешательством человека (или другими средствами) на исходном сервере. Клиенту не может быть гарантировано, что операция была выполнена, даже если код состояния, возвращенный исходным сервером, указывает, что действие было выполнено успешно ...

PUT предназначен для размещения или обновления ресурса на сервере:

Метод PUT запрашивает, чтобы закрытый объект был сохранен под предоставленным Request-URI. Если Request-URI относится к уже существующему ресурсу, вложенный объект СЛЕДУЕТ рассматривать как модифицированную версию того, который находится на исходном сервере. Если Request-URI не указывает на существующий ресурс, и этот URI может быть определен как новый ресурс запрашивающим пользовательским агентом, исходный сервер может создать ресурс с этим URI ...

Для получения полной спецификации посетите:

• http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html

Поскольку текущие браузеры, к сожалению, не поддерживают никаких других глаголов, кроме POST и GET в HTML-формах , вы обычно не можете использовать HTTP в полной мере с ними (хотя вы все равно можете захватить их отправку через JavaScript). Отсутствие поддержки этих методов в HTML-формах привело к появлению URI, содержащих глаголы, например

POST http://example.com/order/1/delete

или даже хуже

POST http://example.com/deleteOrder/id/1

эффективное туннелирование семантики CRUD через HTTP. Но глаголы никогда не должны были быть частью URI. Вместо этого HTTP уже предоставляет механизм и семантику для CRUD ресурса (например, заказа) через методы HTTP. HTTP - это протокол, а не просто служба туннелирования данных.

Итак, чтобы удалить ресурс на веб-сервере, вы должны вызвать

DELETE http://example.com/order/1

и чтобы обновить его, вы бы позвонили

PUT http://example.com/order/1

и предоставить обновленное представление ресурса в теле PUT, чтобы веб-сервер затем применил его.

Итак, если вы создаете своего рода клиент для REST API , вы, скорее всего, заставите его отправлять запросы PUT и DELETE. Это может быть клиент, встроенный в браузер, например, отправляющий запросы через JavaScript, или это может быть какой-то инструмент, работающий на сервере и т. Д.

Для получения более подробной информации посетите:

• http://martinfowler.com/articles/richardsonMaturityModel.html
• Доступны ли методы PUT, DELETE, HEAD и т. Д. В большинстве веб-браузеров?
• Почему в HTML-формах нет методов PUT и DELETE
• Следует ли использовать PUT и DELETE в формах?
• http://amundsen.com/examples/put-delete-forms/
• http://www.quora.com/HTTP/Why-are-PUT-and-DELETE-no-longer-supported-in-HTML5-forms

Использование команды HTTP-запроса, такой как GET, POST, DELETE, PUT и т. Д., Позволяет создавать веб-приложения RESTful. Об этом читайте здесь: http://en.wikipedia.org/wiki/Representational_state_transfer

Самый простой способ увидеть преимущества от этого - посмотреть на этот пример. Каждая платформа MVC имеет Router/Dispatcherсопоставление URL-адресов с контроллерами действий. Таким образом, URL-адрес, подобный этому: /blog/article/1будет вызывать blogController::articleAction($id); Теперь этот маршрутизатор знает только URL-адрес или/blog/article/1/

Но если этот маршрутизатор будет знать весь объект HTTP-запроса, а не только URL-адрес, он сможет получить доступ к команде HTTP-запроса (GET, POST, PUT, DELETE ...) и многим другим полезным материалам о текущем HTTP-запросе.

Это позволит вам настроить приложение так, чтобы оно могло принимать один и тот же URL-адрес и сопоставлять его с разными контроллерами действий в зависимости от глагола HTTP-запроса.

Например:

если вы хотите получить статью 1, вы можете сделать это:

GET /blog/article/1 HTTP/1.1

но если вы хотите удалить статью 1, вы сделаете это:

DELETE /blog/article/1 HTTP/1.1

Обратите внимание, что оба HTTP-запроса имеют одинаковый URI, / blog / article / 1, единственная разница - это команда HTTP-запроса. И на основе этого глагола ваш маршрутизатор может вызывать другой actionController. Это позволяет создавать аккуратные URL-адреса.

Прочтите эти две статьи, они могут вам помочь:

Symfony 2 - Основы HTTP

Symfony 2 - Маршрутизация

Эти статьи посвящены фреймворку Symfony 2, но они могут помочь вам понять, как работают HTTP-запросы и ответы.

Надеюсь это поможет!

Хотя я рискую оказаться непопулярным, я говорю, что в настоящее время они бесполезны .

Я думаю, что они были хорошо задуманы и полезны в прошлом, когда, например, DELETE сообщал серверу об удалении ресурса, найденного по указанному URL-адресу, а PUT (с его родственным PATCH) указывал серверу выполнять обновление идемпотентным образом.

Вещи развивались и URL , стал виртуальным (см перезаписи URL , например) , что делает ресурсы теряют свой первоначальный смысл реальной папки / subforder / файл и так, глаголы действия CRUD , охватываемые HTTP методов протокола (GET, POST, PUT / PATCH, DELETE) потерял .

Возьмем пример:

• / api / entity / list / {id} против GET / api / entity / {id}
• / api / entity / add / {id} против POST / api / entity
• / api / entity / edit / {id} против PUT / api / entity / {id}
• / api / entity / delete / {id} против DELETE / api / entity / {id}

Слева не написан HTTP-метод, по сути это не имеет значения (достаточно POST и GET), а с правой стороны используются соответствующие HTTP-методы.

Правая сторона выглядит элегантно, чисто и профессионально. Представьте, что теперь вам нужно поддерживать код, который использует элегантный API, и вам нужно искать, где выполняется вызов удаления. Вы будете искать «api / entity» и среди результатов увидите, какой из них выполняет DELETE. Или, что еще хуже, у вас есть младший программист, который по ошибке переключил PUT на DELETE, и с URL-адресом произошло то же самое.

На мой взгляд, включение команды действия в URL-адрес имеет преимущества перед использованием соответствующего HTTP-метода для этого действия, даже если это не так элегантно. Если вы хотите увидеть, где выполняется вызов удаления, вам просто нужно найти «api / entity / delete», и вы сразу найдете его.

Создание API без всего массива методов HTTP упрощает его последующее использование и обслуживание.

Безопасные методы: получение ресурса / отсутствие изменений в ресурсе
Идемпотент: отсутствие изменений состояния ресурса при многократном запросе
Небезопасные методы: создание или обновление ресурса / изменение ресурса
Неидемпотентное изменение : изменение состояния ресурса при многократном запросе

Согласно вашему требованию:

1) Для безопасной и идемпотентной операции (Fetch Resource) используйте --------- GET METHOD
2) Для небезопасной и неидемпотентной операции (Insert Resource) используйте --------- POST METHOD
3) Для небезопасной и идемпотентной операции (обновление ресурса) используйте --------- МЕТОД PUT
3) Для небезопасной и идемпотентной операции (удаление ресурса) используйте --------- МЕТОД УДАЛЕНИЯ