PUT & POST при написании API

Question

[Назар Мокринский]

Искал информацию о предназначении разных HTTP методов, всё вполне логично и очевидно кроме PUT и POST.
Второй считается методом общего назначения, и, пожалуй, используется чаще.
Но вот дилемма, а для чего же тогда использовать PUT, и имеет ли смысл использовать PUT/DELETE вместо единого POST?
Если DELETE используют для удаления — то что используют для создания/изменения? Логично было бы PUT/SET, но второго не существует.
Интересует авторитетный источник, либо статья авторитетного автора, c однозначным ответом, чтобы соответствовать каким-то хоть и не описанным официально стандартам.

Answer 1

[Ivan]

en.wikipedia.org/wiki/RESTful#RESTful_web_services

Comments

[Назар Мокринский]

POST: Replace the addressed member of the collection, or if it doesn't exist, create it.

Читал, нет конечной однозначности. Что скажете по поводу разделения POST на POST/PUT/DELETE?
Если разделять — то можно запросы подавать на один URI разными методами, ибо указание операции в URI будет тавтологией. Но тогда нужно всматриваться в метод постоянно, а в случае одного метода и разных URI таких вопросов не возникает.

[Ivan]

Примерно так:
PUT однозначно апдейтит запись и делается на /some/uri/collection/document_id (равнозначно UPDATE в SQL)
POST на коллекцию (/some/uri/collection) создает запись (равнозначен INSERT).
POST на документ ( /some/uri/collection/document_id ) апдейтит документ, если он есть, создает — если нет. (равнозначно INSERT… ON DUPLICATE KEY UPDATE)

[Назар Мокринский]

Спасибо, вы были первыми, и ваше утверждение поддержали. Читал кучу всего, в том числе Wiki, и w3c в разделе о HTTP 1.1, теперь всё стало на свои места.

Answer 2

[Yeah]

Кратко: POST — создание, PUT — обновление
Авторитетного источника применительно к REST не будет, так как REST, строго говоря, не определяет ни POST, ни PUT. REST просто допускает использование HTTP. Следовательно наиболее авторитетный источник по поводу POST/PUT — это спецификация HTTP 1.1:

The POST method is used to request that the origin server accept the entity enclosed in the request as a new subordinate of the resource identified by the Request-URI in the Request-Line.

The PUT method requests that the enclosed entity be stored under the supplied Request-URI.

То есть POST используется для создания подчиненной сущности, а PUT для сохранения сущности.
POST в случае успеха всегда должен возвращать статус 201 (Created) и Location на новый ресурс.
PUT же может возвращать как 201 (если ресурс не найден), так и 204 (No Content) — если ресурс обновлялся.

Comments

[Алексей Гусейнов]

Именно стандарт HTTP 1.1 и надо читать.
Также советую почитать диссертацию Роя Филдинга.

Answer 3

[Сергей Протько]

POST запрос подразумевает создание записи, результатом ее должены быть пустое тело ответа и заголовок location c uri нового объекта.

PUT — подмена записей. Тобиш обновить одно какое-то поле у записи нельзя. Опять же, если вы заменили объект — то вы уже имеете на руках все нужные данные, посему ответом может быть опять же заголовок location.

есть еще метод PATCH, который позволяет именно обновлять запись (конкретное поле или несколько из них). Тут тоже подразумевается возврат только URI. По сути какие либо данные вам может вернуть только GET запрос.

И есть еще куча заморочек со статус кодами, мол 200 это хорошо только для GET, так как оно имеет тело ответа. А для большинства других нужен 204, который говорит что все хорошо, но есть только заголовки.

НО… это если по феншую и именно RESTFull, причем это далеко не все. Обычно дальше GET/POST/PUT/DELETE никто не идет… PATCH вообще редко используют, а вот LINK вообще ниразу не видел что бы на реальных проектах применяли…

Answer 4

[charon]

рекомендую вам не очень парится по поводу теории, а просто ограничиться POST и GET. В нашем проекте сделали всё по правилам, а потом выяснилось, что Флекс-код с другого сервера ни PUT, ни DELETE слать не может, пришлось делать проксирование.

Answer 5

[Владимир Чернышев]

Ориентируетесь на это описание: microformats.org/wiki/rest/urls

Comments

[Назар Мокринский]

Красиво так разложили, спасибо)

Answer 6

[MrMig]

PUT должен быть идемпотентной операцией, т.е. несколько одинаковых последовательных пут-запросов на один урл (и с одинаковыми параметрами) не должны создавать новых объектов.

POST, в свою очередь, может создавать новые объекты при последовательных запросах на один урл.
Другими словами, POST нужно использовать для обращения к «производящим фабрикам».

Первая подручная статья, в которой это объясняется: на английском.

И да, PUT можно сравнить с INSERT… OM DUPLICATE KEY UPDATE.
POST — это чистый INSERT.

Comments

[Виктор П.]

PUT должен быть идемпотентной операцией, т.е. несколько одинаковых последовательных пут-запросов на один урл (и с одинаковыми параметрами) не должны создавать новых объектов.

Это делается как-то автоматически или это вручную надо проверять, условно, если запрос от того же пользователя с теми же самыми полями, то ничего не делаем?
Если делается вручную и есть такое требование, какая разница, запрос придёт POST или PUT?

Answer 7

[kafeman]

PUT — создать новую запись
POST — обновить существующую запись

Comments

[kafeman]

Упс, наоборот…

Answer 8

[Антон Дьячук]

1. Как мне кажется наиболее эффективный метод работы выглядит следующим образом
GET /reports(.:format) reports#index (коллекция)
GET /reports/:report_id/images image#index (коллекция)
POST /reports(.:format) reports#create (создание)
GET /reports/new(.:format) reports#new (инициализация, удобный прием, в разрезе REST можно не рассматривать)
GET /reports/:id/edit(.:format) reports#edit (иницаилизация, данные для редактирования)
GET /reports/:id(.:format) reports#show (конкретный объект)
PUT /reports/:id(.:format) reports#update
DELETE /reports/:id(.:format) reports#destroy
DELETE /reports/:report_id/images images#destroy
PUT для коллекций ниразу не пришлось использовать, выдумывать ничего не буду

2. Вторая часть рест — коды ошибок
Например эффективно используется в связке с jQuery: евенты success, error и т.д. отзываются корректно.

3. (самое важное) Межсистемное взаимодействие.
Restfull API интуитивно понятен разработчикам сторонней системы, если конечно разработчики представляют что такое рест
В любом случае, при межсистемном взаимодействии, важно пользоваться единым стандартом, а разрабатывать его налету — опасно. Большинство выбрали REST, если я не заблуждаюсь.

4. Никакой путаницы.
Ни в приложении, ни во фронтенде, ни в API, при использовании REST, вы совершаете одинаковые действия, с одинаковыми объектами, обращаясь на одинаковые URL, с одинаковыми наборами параметров. Поведение всех систем предсказуемое, все подвластно единой концепции.

Comments

[AlonsoMackenlly]

Всё равно не понимаю. Если происходит первоначальная отправка данных с одного сетевого узла на другой посредством POST - мы создаем. Почему мне кажется, что нарушается концепция в случае, когда происходит повторная отправка данных (когда цель создать недостающие объекты и обновить существующие)? Если POST это создание а PUT обновление, то каким методом архитектурно правильно надо будет отправлять данные из разряда "если нет - создай, если есть обнови"?

[Антон Дьячук]

AlonsoMackenlly, при повторной отправкой данных кто принимает решение на этапе "если нет - создай, если есть обнови"? Если отправитель знает что нужно создать недостающие объекты то POST. Если отправитель знает что нужно обновить то PUT.
Если отправитель ничего не знает, то бэкенду получателя пофиг на метод запроса, потому что алгоритму обработки запроса на метод снаружи наплевать.
Ну то есть, калькулятору пофиг какие числа вы складываете: вы эти числа придумали или прочитали.