В чем разница между POST и PUT HTTP REQUEST?

HTTP PUT:

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

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

HTTP POST:

POST отправляет данные на определенный URI и ожидает, что ресурс в этом URI обработает запрос. На этом этапе веб-сервер может определить, что делать с данными в контексте указанного ресурса. Метод POST не является идемпотентным, однако ответы POST < em> кэшируются, пока сервер устанавливает соответствующие заголовки 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 (перемещен навсегда); затем пользовательский агент МОЖЕТ принять собственное решение относительно перенаправления запроса.

Кроме того, немного более кратко, RFC 7231, раздел 4.3.4 PUT состояния (курсив наш),

4.3.4. PUT

Метод PUT запрашивает, чтобы состояние целевого ресурса было created или replaced с состоянием, определенным представлением, заключенным в полезную нагрузку сообщения запроса.

Использование правильного метода, не имеющего отношения к делу:

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

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

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

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

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

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

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

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

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

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

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

С другой стороны, POST - это способ отправки данных, СВЯЗАННЫХ с заданным URI.

См. HTTP RFC.

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

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

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

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

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

См.: 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.

Определите операции с помощью методов HTTP

Протокол HTTP определяет ряд методов, которые придают семантическое значение запросу. Наиболее распространенные методы HTTP, используемые большинством веб-API RESTful:

GET извлекает представление ресурса по указанному URI. Тело ответного сообщения содержит подробную информацию о запрошенном ресурсе.

POST создает новый ресурс по указанному URI. В теле сообщения запроса содержатся сведения о новом ресурсе. Обратите внимание, что POST также может использоваться для запуска операций, которые фактически не создают ресурсы.

PUT либо создает, либо заменяет ресурс по указанному URI. В теле сообщения запроса указывается ресурс, который должен быть создан или обновлен.

PATCH выполняет частичное обновление ресурса. В теле запроса указывается набор изменений, применяемых к ресурсу.

DELETE удаляет ресурс по указанному URI.

Эффект от конкретного запроса должен зависеть от того, является ли ресурс коллекцией или отдельным элементом. В следующей таблице приведены общие соглашения, принятые в большинстве реализаций RESTful на примере электронной коммерции. Не все из этих запросов могут быть реализованы - это зависит от конкретного сценария.

Различия между POST, PUT и PATCH могут сбивать с толку.

Запрос POST создает ресурс. Сервер назначает URI новому ресурсу и возвращает этот URI клиенту. В REST model вы часто применяете POST запросы к коллекциям. Новый ресурс добавлен в коллекцию. Запрос POST также может использоваться для отправки данных для обработки в существующий ресурс без создания какого-либо нового ресурса.

Запрос PUT создает ресурс или обновляет существующий ресурс. Клиент указывает URI для ресурса. Тело запроса содержит полное представление ресурса. Если ресурс с этим URI уже существует, он заменяется. В противном случае создается новый ресурс, если сервер поддерживает это. PUT запросы чаще всего применяются к ресурсам, которые представляют собой отдельные элементы, такие как конкретный заказчик, а не коллекции. Сервер может поддерживать обновления, но не создание через PUT. Поддерживать ли создание через PUT зависит от того, может ли клиент осмысленно назначать URI ресурсу до того, как он существует. В противном случае используйте POST для создания ресурсов и PUT or PATCH для обновления.

Запрос PATCH выполняет частичное обновление существующего ресурса. Клиент указывает URI для ресурса. В теле запроса указывается набор изменений, применяемых к ресурсу. Это может быть более эффективным, чем использование PUT, потому что клиент отправляет только изменения, а не все представление ресурса. Технически PATCH также может создать новый ресурс (указав набор обновлений для нулевого ресурса), если сервер поддерживает это.

PUT запросы должны быть идемпотентными. Если клиент отправляет один и тот же PUT запрос несколько раз, результаты всегда должны быть одинаковыми (один и тот же ресурс будет изменен с одинаковыми значениями). POST and PATCH запросы не могут быть идемпотентными.

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

Когда использовать тот или иной вариант, должно быть довольно просто, но сложные формулировки сбивают с толку многих из нас.

Когда их использовать:

• Используйте PUT, если вы хотите изменить отдельный ресурс, который уже является частью коллекции ресурсов. PUT полностью заменяет ресурс. Пример: PUT /resources/:resourceId

  Примечание: используйте PATCH, если вы хотите обновить часть ресурса.

• Используйте POST, если хотите добавить дочерний ресурс в коллекцию ресурсов.
  Пример: POST => /resources

В основном:

• Как правило, на практике всегда используйте PUT для операций UPDATE.
• Всегда используйте POST для операций CREATE.

Пример:

GET / company / reports => Получить все отчеты
GET / company / reports / {id} => Получить информацию об отчете по идентификатору
POST / company / reports => < em> Создать новый отчет
PUT / company / reports / {id} => Обновить информацию отчета, идентифицированную "id"
PATCH / company / reports / {id} => Обновить часть информации отчета, обозначенную идентификатором
DELETE / company / reports / {id} => Удалить отчет по "id"