nazarpc
@nazarpc
Open Source enthusiast

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

Искал информацию о предназначении разных HTTP методов, всё вполне логично и очевидно кроме PUT и POST.
Второй считается методом общего назначения, и, пожалуй, используется чаще.
Но вот дилемма, а для чего же тогда использовать PUT, и имеет ли смысл использовать PUT/DELETE вместо единого POST?
Если DELETE используют для удаления — то что используют для создания/изменения? Логично было бы PUT/SET, но второго не существует.
Интересует авторитетный источник, либо статья авторитетного автора, c однозначным ответом, чтобы соответствовать каким-то хоть и не описанным официально стандартам.
  • Вопрос задан
  • 79462 просмотра
Решения вопроса 1
Пригласить эксперта
Ответы на вопрос 7
Yeah
@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) — если ресурс обновлялся.
Ответ написан
Fesor
@Fesor
Full-stack developer (Symfony, Angular)
POST запрос подразумевает создание записи, результатом ее должены быть пустое тело ответа и заголовок location c uri нового объекта.

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

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

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

НО… это если по феншую и именно RESTFull, причем это далеко не все. Обычно дальше GET/POST/PUT/DELETE никто не идет… PATCH вообще редко используют, а вот LINK вообще ниразу не видел что бы на реальных проектах применяли…
Ответ написан
Комментировать
charon
@charon
рекомендую вам не очень парится по поводу теории, а просто ограничиться POST и GET. В нашем проекте сделали всё по правилам, а потом выяснилось, что Флекс-код с другого сервера ни PUT, ни DELETE слать не может, пришлось делать проксирование.
Ответ написан
Комментировать
Ориентируетесь на это описание: microformats.org/wiki/rest/urls
Ответ написан
MrMig
@MrMig
PUT должен быть идемпотентной операцией, т.е. несколько одинаковых последовательных пут-запросов на один урл (и с одинаковыми параметрами) не должны создавать новых объектов.

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

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

И да, PUT можно сравнить с INSERT… OM DUPLICATE KEY UPDATE.
POST — это чистый INSERT.
Ответ написан
kafeman
@kafeman
PUT — создать новую запись
POST — обновить существующую запись
Ответ написан
@Renius
дурак восторженный
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, с одинаковыми наборами параметров. Поведение всех систем предсказуемое, все подвластно единой концепции.
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы