Положи против Поста - ОТДЫХ - PullRequest
Новая
       0

Положи против Поста - ОТДЫХ

2 голосов
/ 07 сентября 2010

При просмотре кода в "petclinic", части примеров Spring 3.0, я заметил следующие строки 

<c:choose>
  <c:when test="${owner.new}"><c:set var="method" value="post"/></c:when>
  <c:otherwise><c:set var="method" value="put"/></c:otherwise>
</c:choose>

В этом обсуждении на SO кажется, что PUT следует использовать для «создания / обновления» и POST для «обновлений».

Что правильно?

Каково влияние использования post для «create» и для «update»?

Примечание. Согласно спецификации HTTP / 1.1. цитируемый в приведенном выше обсуждении SO приведенный выше код, похоже, имеет правильное поведение.

Ответы [ 2 ]

12 голосов
/ 07 сентября 2010

Как POST, так и PUT имеют четко определенное поведение в соответствии со спецификацией HTTP.

Результатом запроса POST должен быть новый ресурс, подчиненный URL-адресу запроса; ответ должен содержать заголовок Location с URL вновь созданного ресурса.

Результатом PUT должно быть обновление ресурса по URL-адресу запроса. если в URL-адресе запроса отсутствует существующий ресурс, можно создать новый.

Путаница возникает из-за того, что POST также используется с формами в качестве механизма для передачи данных формы. Наиболее распространенной реализацией форм является отправка обратно по тому же URL-адресу, по которому находится страница формы, что дает ложное представление о том, что операция POST используется для обновления. Однако в данном конкретном случае страница формы не является ресурсом.

Имея все это в виду, вот правильное (на мой взгляд, конечно :-)) использование:

POST следует использовать для создания новых ресурсов, когда:
- новый ресурс подчиняется существующему ресурсу - идентификатор ресурса / URL неизвестен во время создания

PUT следует использовать для обновления существующих ресурсов с помощью известного URL. Его также можно использовать для создания ресурса по общеизвестному URL; однако, это помогает думать об этом сценарии по-другому - если URL ресурса известен до того, как будет сделан запрос PUT, это можно рассматривать как ресурс в этом месте, уже существующий, но пустой.

6 голосов
/ 07 сентября 2010

Все довольно просто:

  • POST позволяет всему происходить , и оно не ограничивается созданием "подчиненных" ресурсов, но позволяет клиенту "предоставлять"блок данных ... к процессу обработки данных "( RFC 2616 с 9,5 ).POST означает «Вот те данные, которые вы запрашивали только сейчас»
  • PUT используется как противоположность GET.Обычный процесс состоит в том, что вы GET ресурс, каким-то образом модифицируете его, а затем вы УТВЕРЖДАЕТЕ его обратно на тот же URI, с которого вы его получили.PUT означает «Пожалуйста, сохраните этот файл по этому URI».

Единообразие PUT (то есть для хранения файла) позволяет посредникам (например, кэшам) аннулировать любой кэшированныйответы могут иметь именно этот URI (так как они знают, что он собирается измениться).Однородность PUT также позволяет клиентам (которые это понимают) изменять ресурс, сначала извлекая его (GET), а затем отправляет измененную копию обратно (PUT).Это также позволяет клиентам повторять попытки при сбое сети из-за идемпотентности PUT.

Примечание: использование PUT для создания ресурсов сомнительно.Хотя это возможно в рамках спецификации, я не считаю это хорошей идеей, так как использование POST для выполнения поиска не является хорошей идеей, так же как туннелирование SOAP через HTTP не является хорошей идеей.AtomPub прямо заявляет, что PUT не используется для создания записей атомов .

POST s вездесущность обусловлена ​​тем фактом, что HTML определяет <form> элементы, которые приводят к POSTing application/x-www-form-urlencodedсущность, с которой получатель может делать все, что пожелает, включая

  • создание подчиненных ресурсов (ответ обычно сопровождается 201 ответом и Location заголовком)
  • созданиемсовершенно другой ресурс (обычно это ответ 201 и заголовок Location)
  • , создающий множество подчиненных и / или не связанных ресурсов (возможно, с простым ответом, указывающим URI созданных ресурсов)
  • ничего не делая, кроме возврата ответа (например, 200 или 302) (случай, когда, возможно, следует использовать GET)
  • изменение ресурса, который получил сам POST (возврат или перенаправление обратно наобновленный ресурс).
  • удалить один или несколько ресурсов.
  • любую комбинацию перечисленных выше.

ОТолько тот, кто знает, что произойдет в запросе POST, - это пользователь, который инициировал запрос (нажав огромную кнопку «Да, я подтверждаю удаление моего профиля Facebook») и сервер, который обрабатывает запрос.Для остального мира запрос непрозрачен и не означает ничего, кроме «этому URI передаются некоторые данные».

Итак, ответ на ваш вопрос заключается в том, что и POST, и PUT может использоваться как для создания, так и для обновления.

  1. POST часто используется для создания ресурсов (например, AtomPub 9.2 )
  2. Семантика PUT хорошо подходит для изменения ресурсов(например, AtomPub 9.3 )
  3. POST может использоваться для изменения ресурсов (например, форма www редактирует ваш профиль)
  4. PUT технически может использоваться для создания ресурсов (хотя ясоветую против этого)
...