У чому корисність методів запитів PUT та DELETE HTTP?

Я багато читав про це, але не можу дійти висновку з цієї теми.

Але я ніколи не використовував методи PUT або DELETE HTTP Request. Моя тенденція полягає у використанні 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-адреси до actionControllers. Тож URL-адреса така: /blog/article/1буде викликати blogController::articleAction($id); Тепер цей маршрутизатор знає лише URL-адресу або/blog/article/1/

Але якби цей маршрутизатор знав про цілий об’єкт HTTP-запиту замість лише URL-адреси, він міг би отримати доступ до дієслова HTTP-запиту (GET, POST, PUT, DELETE ...) та багатьох інших корисних речей про поточний HTTP-запит.

Це дозволить вам налаштувати програму, щоб вона могла приймати одну і ту ж URL-адресу та зіставляти її з різними ActionControllers залежно від дієслова HTTP-запиту.

Наприклад:

якщо ви хочете отримати статтю 1, ви можете зробити це:

GET /blog/article/1 HTTP/1.1

але якщо ви хочете видалити статтю 1, ви зробите наступне:

DELETE /blog/article/1 HTTP/1.1

Зверніть увагу, що обидва запити HTTP мають однаковий URI, / blog / article / 1, єдина різниця - дієслово HTTP Request. І виходячи з цього дієслова, ваш маршрутизатор може викликати різні actionController. Це дозволяє створювати акуратні URL-адреси.

Прочитайте ці дві статті, вони можуть вам допомогти:

Symfony 2 - Основи HTTP

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

Ці статті стосуються фреймворку Symfony 2, але вони можуть допомогти вам з’ясувати, як працюють запити та відповіді HTTP.

Сподіваюся, це допомагає!

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

Я вважаю, що вони були добре задуманими та корисними в минулому, коли, наприклад, DELETE наказав серверу видалити ресурс, що міститься за вказаною URL-адресою, а PUT (разом із братами PATCH) наказав серверу виконувати оновлення ідемпотентним способом.

Речі еволюціонували, а URL-адреси стали віртуальними (див., Наприклад, переписування URL-адреси ), завдяки чому ресурси втрачають початкове значення реальної папки / підпорядкувача / файлу, а отже, дієслова дії 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", і серед результатів вам доведеться побачити, який з них робить ВИДАЛИТИ. Або ще гірше, у вас є молодший програміст, який помилково переключив PUT на DELETE, і як URL це те саме, що сталося.

На мій погляд, розміщення дієслова дії у URL-адресі має переваги перед використанням відповідного методу HTTP для цієї дії, навіть якщо це не так елегантно. Якщо ви хочете побачити, де здійснюється виклик видалення, вам просто потрібно знайти "api / entity / delete", і ви знайдете його відразу.

Побудова API без усього масиву методів HTTP полегшує споживання та підтримку в подальшому

Безпечні методи: Отримати ресурс / Без змін у ресурсі
Ідемпотент: Без змін у статусі ресурсу, якщо його запитували багато разів.
Небезпечні методи: Створення або оновлення ресурсу / Модифікація у ресурсі
Неідемпотент: Зміна стану ресурсу за запитом багато разів

Відповідно до ваших вимог:

1) Для безпечної та неімпотентної роботи (Fetch Resource) використовувати --------- ОТРИМАТИ МЕТОД
2) Для небезпечної та неімпотентної роботи (Вставити ресурс) використовувати --------- POST METHOD
3) Для небезпечної та ідемпотентної операції (Ресурс оновлення) використовуйте --------- МЕТОД ВСТАНОВЛЕННЯ
3) Для небезпечної та ідемпотентної операції (Видалити ресурс) використовуйте --------- ВИДАЛИТИ МЕТОД