Які методи HTTP відповідають яким методам CRUD?

У програмуванні стилю RESTful ми повинні використовувати методи HTTP як наші будівельні блоки. Я трохи розгублений, хоча які методи відповідають класичним методам CRUD. GET / Read та DELETE / Delete досить очевидні.

Однак у чому різниця між PUT / POST? Чи співпадають вони один із одним із створенням та оновленням?

Create = PUT with a new URI
         POST to a base URI returning a newly created URI
Read   = GET
Update = PUT with an existing URI
Delete = DELETE

PUT може зіставляти як Create, так і Update, залежно від існування URI, що використовується з PUT.

POST карти для створення.

Виправлення: POST також може відображати оновлення, хоча зазвичай використовується для Create. POST також може бути частковим оновленням, тому нам не потрібен запропонований метод PATCH.

Весь ключ полягає в тому, чи змінюєте ви безвідмовну зміну чи ні. Тобто, якщо вчинити дії над повідомленням двічі, це призведе до того, що там буде "те саме", як якщо б це було зроблено лише один раз, ви отримали ідентичну зміну, і її слід відобразити на PUT. Якщо ні, він відображається в POST. Якщо ви ніколи не дозволяєте клієнту синтезувати URL-адреси, PUT досить близький до оновлення, і POST може обробляти Створити просто чудово, але це, звичайно, не єдиний спосіб зробити це; якщо клієнт знає, що хоче створити, /foo/abcі знає, який вміст туди розмістити, він працює чудово як PUT.

Канонічний опис пошти - це коли ви зобов’язуєтесь щось придбати: це дія, яку ніхто не хоче повторити, не знаючи про це. Навпаки, встановлення відправки для замовлення заздалегідь можна зробити за допомогою PUT просто чудово: не має значення, якщо вам кажуть надіслати 6 Anywhere Dr, Nowherevilleраз, два чи сто разів: це все одно та сама адреса. Це означає, що це оновлення? Можливо ... Все залежить від того, як ви хочете написати бек-енд. (Зверніть увагу, що результати можуть бути не ідентичними: ви можете повідомити про це користувачеві, коли він востаннє робив PUT як частину представлення ресурсу, що забезпечило б, щоб повторні PUT не викликали однаковий результат, але результат все одно бути "однаковим" у функціональному сенсі.)

Я шукав ту саму відповідь, ось що кажуть IBM. IBM Link

POST            Creates a new resource.
GET             Retrieves a resource.
PUT             Updates an existing resource.
DELETE          Deletes a resource.

Зараз (2016 р.) Останніми дієсловами HTTP є GET, POST, PATCH , PUT та DELETE

Огляд

• HTTP GET - ВИБІР / Запит
• HTTP PUT - ОНОВЛЕННЯ
• HTTP POST - ВСТАВКА / Створення
• HTTP PATCH - коли PUT ting повне представлення ресурсів є громіздким і використовує більшу пропускну здатність, наприклад: коли вам доведеться частково оновити стовпець
• HTTP DELETE - DELETE

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

Якщо ви зацікавлені в розробці API REST, це ще одне читання! веб-версія веб- сховища github

Існує чудова відео-розмова на youtube від stormpath, яка фактично пояснює це, URL-адреса повинна переходити до правильної частини відео:

Штурмове відео на YouTube

Крім того, варто дивитися, що це більше години розмови, але дуже цікаво, якщо ви думаєте про те, щоб вкласти час у побудову ПІДПРИЄМНОГО ППІ.

Це залежить від конкретної ситуації .. але загалом:

PUT = оновити або змінити конкретний ресурс за допомогою конкретного URI ресурсу.

POST = створити новий ресурс під джерелом даного URI.

Тобто

Редагування публікації в блозі:

ПУТ: / блог / запис / 1

Створіть новий:

POST: / блог / запис

PUT може створити новий ресурс за деяких обставин, коли URI нового ресурсу буде зрозумілим перед запитом. POST може використовуватися і для впровадження кількох інших випадків використання, які не охоплені іншими (GET, PUT, DELETE, HEAD, OPTIONS)

Загальне розуміння для систем CRUD - GET = запит, POST = створити, Put = оновити, DELETE = видалити

Складаючими елементами REST є в основному ресурси (та URI) та гіпермедіа. У цьому контексті GETє спосіб отримати представлення ресурсу (який дійсно можна відобразити SELECTв CRUD термінах).

Однак не слід сподіватися на однозначне відображення між операціями CRUD та HTTP-дієсловами. Основна відмінність між PUTі в POSTтому, що стосується їх ідентичного властивості. POSTтакож частіше використовується для часткових оновлень, оскільки PUTзагалом передбачає надсилання повного нового представлення ресурсу.

Я б запропонував прочитати це:

• http://roy.gbiv.com/untangled/2009/it-is-okay-to-use-post
• http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven

Специфікація HTTP також є корисною посиланням:

Метод PUT вимагає, щоб вкладений об'єкт зберігався під наданим URI-запитом.

[...]

Принципова відмінність запитів POST від PUT відображається в різному значенні Request-URI. URI у запиті POST ідентифікує ресурс, який буде обробляти додану сутність. Цей ресурс може бути процесом прийняття даних, шлюзом до якогось іншого протоколу або окремим об'єктом, який приймає примітки. На відміну від цього, URI у запиті PUT ідентифікує об'єкт, укладений із запитом - агент користувача знає, для чого призначений URI, і сервер НЕ повинен намагатися застосувати запит до якогось іншого ресурсу. Якщо сервер бажає, щоб запит було застосовано до іншого URI,

Взагалі кажучи, це схема, яку я використовую:

• HTTP GET - ВИБІР / Запит
• HTTP PUT - ОНОВЛЕННЯ
• HTTP POST - ВСТАВКА / Створення
• HTTP DELETE - DELETE

Проект Symfony намагається підтримувати свої HTTP-методи, об'єднані з методами CRUD, і їх список пов’язує їх так:

• GET Отримайте ресурс із сервера
• POST Створіть ресурс на сервері
• PUT Оновіть ресурс на сервері
• ВИДАЛИТИ Видалити ресурс із сервера

Варто зазначити, що, як кажуть на цій сторінці, "насправді багато сучасних браузерів не підтримують методи PUT і DELETE".

Як я пам’ятаю, Symfony «підробляє» PUT і DELETE для тих браузерів, які не підтримують їх під час генерування форм, щоб намагатися максимально наблизитись до використання теоретично правильного методу HTTP, навіть коли браузер не підтримує це.