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

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

23 ответа

Решение

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 для создания или изменения ресурса.

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

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 должен быть идемпотентным - несколько PUT с одинаковыми данными на один и тот же URL-адрес должны подойти, если несколько POST могут создавать несколько объектов или что-то еще, что делает ваше действие POST.

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

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 обычно "заменяет" существующую запись, если она есть, и создает, если ее там нет...

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

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

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

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

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

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

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

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 и т. Д. Являются в основном пустяковыми вопросами.

Пожалуйста, смотрите: 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.

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

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

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

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


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

В общем:

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

Пример:

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

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

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

GET: Запросы с использованием GET только извлекают данные, то есть он запрашивает представление указанного ресурса

POST: Отправляет данные на сервер для создания ресурса. Тип тела запроса указывается заголовком Content-Type. Это часто вызывает изменение состояния или побочные эффекты на сервере

PUT: Создает новый ресурс или заменяет представление целевого ресурса на полезную нагрузку запроса.

PATCH: Используется для частичного изменения ресурса

DELETE: Удаляет указанный ресурс

TRACE: Он выполняет проверку обратной связи по пути к целевому ресурсу, предоставляя полезный механизм отладки

OPTIONS: Используется для описания параметров связи для целевого ресурса, клиент может указать URL-адрес для метода OPTIONS или звездочку (*) для ссылки на весь сервер.

HEAD: Он запрашивает ответ, идентичный ответу запроса GET, но без тела ответа

CONNECT: Он устанавливает туннель к серверу, идентифицированному целевым ресурсом, может использоваться для доступа к веб-сайтам, использующим SSL (HTTPS)

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

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

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

Стоит упомянуть, что POST подвержен некоторым распространенным атакам CSRF в то время как PUT нет.

CSRF ниже не возможны сPUT когда жертва посещает attackersite.com:

Обычный запрос (куки отправляются): (PUT не поддерживается значение атрибута)

<form id="myform" method="post" action="http://target.site.com/deleteUser" >
    <input type="hidden" name="userId" value="5">
</form>
<script>document.createElement('form').submit.call(document.getElementById('myform'));</script>

XHR-запрос (куки отправляются): (PUT вызовет предполетный запрос)

var xhr = new XMLHttpRequest();
xhr.open("POST", "http://target.site.com/deleteUser");
xhr.withCredentials=true;
xhr.send(["userId=5"]);

Простыми словами можно сказать:

1.HTTP Get: используется для получения одного или нескольких элементов.

2.HTTP-сообщение: используется для создания элемента

3.HTTP Put: используется для обновления элемента

4.HTTP-патч: используется для частичного обновления элемента.

5.HTTP Delete: используется для удаления элемента

REST-полное использование

POST используется для создания нового ресурса, а затем возвращает ресурс URI

EX 
      REQUEST : POST ..../books
        {
        "book":"booName",
        "author":"authorName"
        }

Этот вызов может создать новую книгу и вернуть эту книгу URI

Response ...THE-NEW-RESOURCE-URI/books/5

PUT используется для замены ресурса, если этот ресурс существует, просто обновите его, но если этот ресурс не существует, создайте его,

REQUEST : PUT ..../books/5
{
"book":"booName",
"author":"authorName"
}

С PUT мы знаем идентификатор ресурса, но POST вернет новый идентификатор ресурса

Использование без REST-ful

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

PUT используется для размещения или замены буквального содержимого по определенному URL-адресу

Еще одно различие между стилями REST-ful и без REST-ful

POST неидемпотентная операция: она вызовет некоторые изменения, если будет выполняться несколько раз с одним и тем же запросом.

PUT Идемпотентная операция: при многократном выполнении с одним и тем же запросом побочных эффектов не будет.

На самом деле нет никакой разницы, кроме названия. На самом деле между GET и другими есть принципиальная разница. С помощью метода "GET"-Request вы отправляете данные в строке url-адреса, которые разделяются сначала вопросительным знаком, а затем знаком &.

Но с методом запроса "POST" вы не можете передавать данные через URL-адрес, но вы должны передать данные как объект в так называемом "теле" запроса. Затем на стороне сервера вы должны прочитать тело полученного контента, чтобы получить отправленные данные. Но, с другой стороны, нет возможности отправлять контент в теле, когда вы отправляете "GET"-Request.

Утверждение, что "GET" предназначен только для получения данных, а "POST"- для отправки данных, абсолютно неверно. Никто не может запретить вам создавать новый контент, удалять существующий контент, редактировать существующий контент или делать что-либо в бэкэнде на основе данных, отправленных запросом "GET" или запросом "POST". И никто не может помешать вам закодировать серверную часть таким образом, чтобы с помощью "POST"-запроса клиент запрашивал некоторые данные.

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

Есть только эти два ОСНОВНЫХ МЕТОДА. ПОЛУЧИТЬ и ОТПРАВИТЬ. Но их отличает их структура, а не то, что вы кодируете в серверной части. В бэкэнде вы можете кодировать все, что хотите, с полученными данными. Но с запросом "POST" вы должны отправлять / получать данные в теле, а не в строке url-адреса, а с запросом "GET" вы должны отправлять / получать данные в строке url-address, а не в тело. Вот и все.

Все остальные методы, такие как "PUT", "DELETE" и т. Д., Имеют ту же структуру, что и "POST".

Метод POST в основном используется, если вы хотите несколько скрыть контент, потому что все, что вы пишете в строке url-адреса, будет сохранено в кеше, а метод GET аналогичен записи строки url-адреса с данными. Поэтому, если вы хотите отправить конфиденциальные данные, которые не всегда обязательно являются именем пользователя и паролем, но, например, некоторые идентификаторы или хэши, которые вы не хотите отображать в строке url-address-line, вам следует использовать метод POST.

Также длина строки URL-адреса ограничена 1024 символами, в то время как метод "POST" не ограничен. Поэтому, если у вас большой объем данных, возможно, вы не сможете отправить его с помощью GET-запроса, но вам нужно будет использовать POST-запрос. Так что это еще один плюс для POST-запроса.

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

Методы запроса GET, PUT и DELETE представляют собой операции CRUD (создание, чтение, обновление и удаление), то есть операции управления данными, в отношении состояния целевого ресурса (того, который определяется URI запроса):

  • GET должен читать состояние целевого ресурса;
  • PUT должен создавать или обновлять состояние целевого ресурса;
  • DELETE должен удалить состояние целевого ресурса.

Другой метод запроса POST. Он не должен создавать состояние целевого ресурса, такого как PUT, потому что это операция процесса с целью более высокого уровня, чем CRUD (см. RFC 7231, § 4.3.3). Процесс может создать ресурс, но отличный от целевого ресурса, в противном случае следует использовать метод запроса цели нижнего уровня PUT, поэтому даже в этом случае это не делает его операцией CRUD.

Разница между операциями CRUD (GET, PUT и DELETE в HTTP) и операциями без CRUD (POST в HTTP) - это разница между абстрактными типами данных и объектами, которые Алан Кей подчеркивал в большинстве своих выступлений и в своей статье ACM http://worrydream.com/EarlyHistoryOfSmalltalk/:

Что я получил от Simula, так это то, что теперь вы можете заменить привязки и назначения целями. Последнее, что вы хотели бы от любого программиста, - это возиться с внутренним состоянием, даже если оно представлено образно. Вместо этого объекты должны быть представлены как сайты более высокого уровня поведения, более подходящие для использования в качестве динамических компонентов.

[…] К сожалению, большая часть того, что сегодня называют "объектно-ориентированным программированием", является просто старым стилем программирования с более причудливыми конструкциями. Многие программы загружаются операциями "в стиле присваивания", которые теперь выполняются более дорогими присоединенными процедурами.

[…] Утверждения о назначении - даже абстрактные - выражают цели очень низкого уровня, и для выполнения чего-либо потребуется их больше. […] Другой способ подумать обо всем этом: хотя позднее связывание автоматического выделения памяти не делает ничего, что не может сделать программист, его присутствие приводит как к более простому, так и к более мощному коду. ООП - это стратегия позднего связывания для многих вещей, и все они вместе сдерживают хрупкость и рост размеров намного дольше, чем старые методологии.

Post и Put в основном используются для публикации данных и другого обновления данных. Но вы можете сделать то же самое только с почтовым запросом.

Разница между POST и PUT заключается в том, что запросы PUT являются идемпотентными. То есть, вызов одного и того же запроса PUT несколько раз всегда будет давать один и тот же результат. Напротив, повторный вызов POST - запроса имеет побочные эффекты многократного создания одного и того же ресурса.

И PUT, и POST - это методы отдыха.

PUT - если мы сделаем один и тот же запрос дважды, используя PUT с одинаковыми параметрами оба раза, второй запрос не будет иметь никакого эффекта. Вот почему PUT обычно используется для сценария Update, вызывая Update более одного раза с одними и теми же параметрами, не делает ничего, кроме начального вызова, поэтому PUT является идемпотентным.

POST не идемпотентен, например Create создаст две отдельные записи в цель, поэтому он не идемпотентен, поэтому CREATE широко используется в POST.

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

Другие вопросы по тегам