В чем разница между 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 кэшируются, если сервер устанавливает соответствующие заголовки Cache-Control и Expires.

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

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

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

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

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

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

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

Одним из преимуществ 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, либо заменить существующую книгу на ID 5.

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

1) GET: – Используется, когда клиент запрашивает ресурс на веб-сервере.

2) HEAD: – Используется, когда клиент запрашивает некоторую информацию о ресурсе, но не запрашивает сам ресурс.

3) POST: – используется, когда клиент отправляет информацию или данные на сервер, например, заполняя онлайн-форму (т.е. отправляет на веб-сервер большое количество сложных данных).

4) PUT: – используется, когда клиент отправляет заменяющий документ или загружает новый документ на веб-сервер под URL-адресом запроса.

5) DELETE: – Используется, когда клиент пытается удалить документ с веб-сервера, указанный URL-адресом запроса.

6) TRACE: – используется, когда клиент запрашивает доступные прокси или промежуточные серверы, изменяющие запрос, чтобы объявить себя.

7) ОПЦИИ: – Используется, когда клиент хочет определить другие доступные методы для извлечения или обработки документа на веб-сервере.

8) CONNECT: – Используется, когда клиент хочет установить прозрачное соединение с удаленным хостом, как правило, для обеспечения SSL-шифрованной связи (HTTPS) через HTTP-прокси.

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

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

См. HTTP RFC

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

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

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

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

Согласно RFC , разница между PUT и POST находится в URI запроса. URI, идентифицированный POST, определяет объект, который будет обрабатывать запрос POST. URI в запросе PUT включает объект в запрос. Таким образом, POST /v1/coffees/orders означает создание нового ресурса и возврат идентификатора для описания ресурса. Напротив, PUT /v1/coffees/orders/1234 означает обновление ресурса, идентифицированного « 1234 », если оно существует; иначе создайте новый порядок и используйте URI orders/1234 чтобы идентифицировать его.

PUT and POST can both be used to create or update methods. The usage of the method depends on the idempotent behavior expected from the method as well as the location of the resource to identify it.

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

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

См.: 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 идентифицирует ресурс, который будет обрабатывать заключенный объект. Этот ресурс может быть процессом принятия данных, шлюзом к другому протоколу или отдельным объектом, который принимает annotations. Напротив, URI в запросе PUT идентифицирует объект, заключенный с запросом – пользовательский агент знает, что такое URI, и сервер НЕ ДОЛЖЕН пытаться применить запрос к другому ресурсу.

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

 obj.set_attribute(value) # A POST request. 

И это:

 obj.attribute = value # A PUT request. 

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

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

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

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

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

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

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

Разница между PUT и POST заключается в следующем:

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

Клиент использует POST, когда сервер отвечает за решение, какой URI должен иметь новый ресурс.

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