В чем разница между POST и PUT HTTP REQUEST? - PullRequest
699 голосов
/ 20 сентября 2008

Кажется, что они оба посылают данные на сервер внутри тела, так чем они отличаются?

Ответы [ 12 ]

704 голосов
/ 20 сентября 2008

HTTP PUT:

PUT помещает файл или ресурс по определенному URI и точно по этому URI. Если в этом URI уже есть файл или ресурс, PUT заменяет этот файл или ресурс. Если там нет файла или ресурса, PUT создает его. PUT идемпотент , но, как ни парадоксально, ответы PUT не кэшируются.

HTTP 1.1 RFC-расположение для PUT

HTTP POST:

POST отправляет данные на определенный URI и ожидает, что ресурс на этом URI обработает запрос. В этот момент веб-сервер может определить, что делать с данными в контексте указанного ресурса. Метод POST не является идемпотентным , однако ответы POST могут кэшироваться, если сервер устанавливает соответствующие заголовки Cache-Control и Expires.

Официальный HTTP RFC определяет POST:

  • Аннотация существующих ресурсов;
  • Размещение сообщения на доске объявлений, в группе новостей, списке рассылки, или аналогичная группа статей;
  • Предоставление блока данных, например, результата отправки форма, к процессу обработки данных;
  • Расширение базы данных с помощью операции добавления.

HTTP 1.1 RFC-местоположение для POST

Разница между POST и PUT:

RFC сам объясняет разницу в ядре:

Принципиальная разница между Запросы POST и PUT отражены в различное значение Request-URI. URI в запросе POST определяет ресурс, который будет обрабатывать вложенную сущность. Тот ресурс может быть принимающим данные процесс, ворота в какой-то другой протокол или отдельное лицо, которое принимает аннотации В отличие от URI в запросе PUT идентифицирует юридическое лицо, приложенное к запросу - пользовательский агент знает, что такое URI предназначен и сервер не должен попытаться применить запрос к некоторым другой ресурс. Если сервер желает что запрос будет применен к другой URI, он ДОЛЖЕН отправить ответ 301 (постоянно перемещенный); пользовательский агент МОЖЕТ сделать свое собственное решение относительно того, следует ли перенаправить запрос.

Используя правильный метод, не связанный в стороне:

Одним из преимуществ REST ROA по сравнению с SOAP является то, что при использовании HTTP REST ROA он поощряет правильное использование HTTP-глаголов / методов. Так, например, вы будете использовать PUT, только если вы хотите создать ресурс именно в этом месте. И вы никогда не будете использовать GET для создания или изменения ресурса.

175 голосов
/ 20 сентября 2008

Только семантика.

HTTP PUT должен принять тело запроса, а затем сохранить его на ресурсе, идентифицированном URI.

HTTP POST является более общим. Предполагается инициировать действие на сервере. Это может быть сохранение тела запроса в ресурсе, идентифицированном URI, или это может быть другой URI, или это может быть другое действие.

PUT равен как загрузка файла. Положенный в URI влияет именно на этот URI. POST для URI может вообще иметь какой-либо эффект.

105 голосов
/ 20 сентября 2008

Чтобы привести примеры ресурсов в стиле REST:

"POST / books" с кучей информации о книге может создать новую книгу и ответить новым URL-адресом, идентифицирующим эту книгу: "/books/5".

«PUT / books / 5» должен будет либо создать новую книгу с идентификатором 5, либо заменить существующую книгу с идентификатором 5.

В нересурсном стиле POST может использоваться практически для всего, что имеет побочный эффект. Еще одно отличие состоит в том, что PUT должен быть идемпотентным - несколько PUT с одинаковыми данными на один и тот же URL-адрес должны подойти, если несколько POST могут создавать несколько объектов или что-то еще, что делает ваше действие POST.

55 голосов
/ 20 сентября 2008

PUT предназначен как метод для «загрузки» материала в определенный URI или перезаписи того, что уже есть в этом URI.

POST, с другой стороны, представляет собой способ отправки данных, связанных с данным URI.

См. HTTP RFC

38 голосов
/ 15 февраля 2013

Насколько я знаю, PUT в основном используется для обновления записей.

  1. POST - для создания документа или любого другого ресурса

  2. PUT - для обновления созданного документа или любого другого ресурса.

Но чтобы понять, что PUT обычно «заменяет» существующую запись, если она есть, и создает, если ее там нет ..

16 голосов
/ 20 сентября 2008

Другие уже опубликовали отличные ответы, я просто хотел добавить, что с большинством языков, сред и сценариев использования вы будете иметь дело с POST гораздо, гораздо чаще, чем с PUT. До такой степени, что PUT, DELETE и т. Д. В основном пустяковые вопросы.

14 голосов
/ 08 марта 2018
  1. GET : получение данных с сервера. Не должно иметь другого эффекта.
  2. POST : отправляет данные на сервер для создания нового объекта. Часто используется при загрузке файла или отправке веб-формы.
  3. PUT : аналогично POST, но используется для замены существующего объекта.
  4. PATCH : аналогично PUT, но используется для обновления только определенных полей в существующей сущности.
  5. УДАЛИТЬ : Удаляет данные с сервера.
  6. TRACE : Предоставляет способ проверить, что сервер получает. Он просто возвращает то, что было отправлено.
  7. ОПЦИИ : Позволяет клиенту получать информацию о методах запроса, поддерживаемых службой. Соответствующий заголовок ответа - Разрешить с поддерживаемыми методами. Также используется в CORS в качестве предварительного запроса для информирования сервера о фактическом методе запроса и запроса пользовательских заголовков.
  8. HEAD : Возвращает только заголовки ответа.
  9. CONNECT : Используется браузером, когда он знает, что разговаривает с прокси, и окончательный URI начинается с https: //. Назначение CONNECT - разрешить сквозной зашифрованный сеанс TLS, чтобы данные не могли быть прочитаны прокси-сервером.
11 голосов
/ 20 сентября 2008

POST считается методом фабричного типа. Вы включаете в него данные для создания того, что вы хотите, и все, что находится на другом конце, знает, что с этим делать. PUT используется для обновления существующих данных по заданному URL-адресу или для создания чего-то нового, когда вы знаете, каким будет URI, а он еще не существует (в отличие от POST, который создает что-то и возвращает URL-адрес это при необходимости).

9 голосов
/ 06 апреля 2017

REST просит разработчиков использовать методы HTTP явно и в соответствии с определение протокола. Этот базовый принцип проектирования REST устанавливает взаимно-однозначное сопоставление операции создания, чтения, обновления и удаления (CRUD) и методы HTTP. Согласно этому отображение:

• Чтобы создать ресурс на сервере, используйте POST.

• Чтобы получить ресурс, используйте GET.

• Чтобы изменить состояние ресурса или обновить его, используйте PUT.

• Чтобы удалить или удалить ресурс, используйте DELETE.

Дополнительная информация: RESTful Web-сервисы: основы от IBM

9 голосов
/ 05 апреля 2014

Пожалуйста, смотрите: http://zacharyvoase.com/2009/07/03/http-post-put-diff/

В последнее время меня очень раздражает популярное заблуждение веб-разработчиков о том, что POST используется для создания ресурса, а PUT используется для его обновления / изменения.

Если вы посмотрите на страницу 55 RFC 2616 («Протокол передачи гипертекста - HTTP / 1.1»), Раздел 9.6 («PUT»), вы увидите, для чего фактически используется PUT:

Метод PUT запрашивает, чтобы вложенный объект был сохранен под предоставленным Request-URI.

Есть также удобный параграф, объясняющий разницу между POST и PUT:

Принципиальное различие между запросами POST и PUT отражается в различном значении Request-URI. URI в запросе POST идентифицирует ресурс, который будет обрабатывать вложенный объект. Этот ресурс может быть процессом приема данных, шлюзом к другому протоколу или отдельным объектом, принимающим аннотации. Напротив, URI в запросе PUT идентифицирует объект, заключенный в запросе - пользовательский агент знает, для чего предназначен URI, и сервер НЕ ДОЛЖЕН пытаться применить запрос к какому-либо другому ресурсу.

В нем ничего не говорится о разнице между обновлением / созданием, потому что дело не в этом. Речь идет о разнице между этим:

obj.set_attribute(value) # A POST request.

А это:

obj.attribute = value # A PUT request.

Так что, пожалуйста, остановите распространение этого популярного заблуждения. Прочитайте ваши RFC.

...