Ответы:
HTTP PUT:
PUT помещает файл или ресурс по определенному URI и точно по этому URI. Если в этом URI уже есть файл или ресурс, PUT заменяет этот файл или ресурс. Если там нет файла или ресурса, PUT создает его. PUT является идемпотентом , но, как это ни парадоксально, ответы PUT не кэшируются.
HTTP 1.1 RFC расположение для PUT
HTTP POST:
POST отправляет данные на определенный URI и ожидает, что ресурс на этом URI обработает запрос. В этот момент веб-сервер может определить, что делать с данными в контексте указанного ресурса. Метод POST не идемпотентный , однако POST ответы являются кэшируются, пока сервер устанавливает соответствующий Cache-Control и Истекает заголовки.
Официальный HTTP RFC определяет POST:
HTTP 1.1 RFC расположение для POST
Разница между POST и PUT:
Сам RFC объясняет основное различие:
Принципиальное различие между запросами POST и PUT отражается в различном значении Request-URI. URI в запросе POST идентифицирует ресурс, который будет обрабатывать вложенный объект. Этот ресурс может быть процессом приема данных, шлюзом к другому протоколу или отдельным объектом, принимающим аннотации. Напротив, URI в запросе PUT идентифицирует объект, заключенный в запросе - пользовательский агент знает, для чего предназначен URI, и сервер НЕ ДОЛЖЕН пытаться применить запрос к какому-либо другому ресурсу. Если сервер желает, чтобы запрос был применен к другому URI, он ДОЛЖЕН послать ответ 301 (перемещен постоянно); Затем пользовательский агент МОЖЕТ принять собственное решение относительно того, следует ли перенаправить запрос.
Кроме того, и более кратко, в разделе 4.3.4 RFC 7231 раздел PUT (выделение добавлено),
4.3.4. ПОЛОЖИЛ
Метод PUT запрашивает, чтобы состояние целевого ресурса было
createdилиreplacedс состоянием, определенным представлением, заключенным в полезную нагрузку сообщения запроса.
Используя правильный метод, не связанный в стороне:
Одним из преимуществ REST ROA по сравнению с SOAP является то, что при использовании HTTP REST ROA он поощряет правильное использование глаголов / методов HTTP. Так, например, вы будете использовать PUT, только если вы хотите создать ресурс именно в этом месте. И вы никогда не будете использовать GET для создания или изменения ресурса.
If the Request-URI does not point to an existing resource [...] the origin server *can* create the resource with that URI. Так что реализация PUT, которая отказывается создавать ресурс, если его нет, будет правильной, верно? Если да, то происходит ли это на практике? Или реализации обычно также создают на PUT?
Только семантика.
PUTПредполагается, что HTTP принимает тело запроса, а затем сохраняет его в ресурсе, идентифицированном 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.
PUT предназначен как метод для «загрузки» материала в определенный URI или перезаписи того, что уже есть в этом URI.
С другой стороны, POST - это способ отправки данных, связанных с данным URI.
Обратитесь к HTTP RFC
Насколько я знаю, PUT в основном используется для обновления записей.
POST - для создания документа или любого другого ресурса
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.
POST считается методом фабричного типа. Вы включаете в него данные для создания того, что вы хотите, и все, что находится на другом конце, знает, что с этим делать. PUT используется для обновления существующих данных по заданному URL-адресу или для создания чего-то нового, когда вы знаете, каким будет URI, а он еще не существует (в отличие от POST, который создает что-то и возвращает URL-адрес это при необходимости).
REST просит разработчиков использовать методы HTTP явно и в соответствии с определением протокола. Этот базовый принцип проектирования REST устанавливает взаимно-однозначное сопоставление между операциями создания, чтения, обновления и удаления (CRUD) и методами HTTP. Согласно этому отображению:
• Чтобы создать ресурс на сервере, используйте POST.
• Чтобы получить ресурс, используйте GET.
• Чтобы изменить состояние ресурса или обновить его, используйте PUT.
• Чтобы удалить или удалить ресурс, используйте DELETE.
Дополнительная информация: RESTful Web-сервисы: основы от IBM
Это должно быть довольно просто, когда использовать один или другой, но сложные формулировки являются источником путаницы для многих из нас.
Используйте, PUTкогда вы хотите изменить отдельный ресурс, который уже является частью коллекции ресурсов. PUTзаменяет ресурс в полном объеме. Пример:PUT /resources/:resourceId
Sidenote: используйте, PATCHесли вы хотите обновить часть ресурса.
POSTесли вы хотите добавить дочерний ресурс в коллекцию ресурсов. POST => /resourcesPUTдля операций 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 заключается в том, что PUT является идемпотентным, то есть многократный вызов одного и того же запроса PUT всегда будет приводить к одному и тому же результату (что не является побочным эффектом), в то время как, с другой стороны, повторный вызов запроса POST может иметь ( дополнительные) побочные эффекты от создания одного и того же ресурса несколько раз.
GET : Запросы с использованием GET только извлекают данные, то есть он запрашивает представление указанного ресурса
POST: Отправляет данные на сервер для создания ресурса. Тип тела запроса указывается заголовком Content-Type. Это часто вызывает изменение состояния или побочные эффекты на сервере
PUT : Создает новый ресурс или заменяет представление целевого ресурса на полезную нагрузку запроса
PATCH : Используется для частичного изменения ресурса
DELETE : Удаляет указанный ресурс
TRACE : Он выполняет проверку обратной связи по пути к целевому ресурсу, предоставляя полезный механизм отладки
OPTIONS : Он используется для описания параметров связи для целевого ресурса, клиент может указать URL-адрес для метода OPTIONS или звездочку (*) для ссылки на весь сервер.
HEAD : Он запрашивает ответ, идентичный ответу запроса GET, но без тела ответа
CONNECT : Он устанавливает туннель к серверу, идентифицированному целевым ресурсом, может использоваться для доступа к веб-сайтам, использующим SSL (HTTPS)
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-полное использование
POST используется для инициирования действия на стороне сервера, это действие может создавать или не создавать ресурс, но это действие будет иметь побочные эффекты, всегда что-то меняет на сервере
PUT используется для размещения или замены буквального содержимого по определенному URL
Еще одно отличие в стилях REST-ful и non-REST-ful
POST является неидемпотентной операцией: она вызовет некоторые изменения, если выполняется несколько раз с одним и тем же запросом.
PUT Идемпотентная операция: она не будет иметь побочных эффектов, если выполняется несколько раз с одним и тем же запросом.
Было бы стоит упомянуть , что POSTявляется предметом некоторых общего Cross-Site Request подлог (CSRF) атак , пока PUTнет.
Приведенный ниже CSRF невозможенPUT при посещении жертвы attackersite.com.
Эффект атаки является то , что жертва непреднамеренно удаляет пользователь только потому , что она (жертва) была зарегистрирована в качестве adminна target.site.com, перед посещением attackersite.com:
Обычный запрос (куки отправляются): ( PUTне поддерживается значение атрибута)
Код на attackersite.com:
<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-запрос (файлы cookie отправляются): ( PUTвызовет предварительный запрос, ответ которого не позволит браузеру запрашивать deleteUserстраницу)
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 Patch: используется для частичного обновления элемента
5.HTTP Delete: используется для удаления элемента
На самом деле нет никакой разницы, кроме их названия. На самом деле есть принципиальная разница между GET и другими. С помощью метода «GET» -Request вы отправляете данные в строке url-address, которые сначала разделяются знаком вопроса, а затем знаком &.
Но с помощью метода "POST" -request вы не можете передавать данные через URL, но вы должны передавать данные как объект в так называемом "теле" запроса. На стороне сервера вы должны затем прочитать тело полученного контента, чтобы получить отправленные данные. Но с другой стороны нет возможности отправлять контент в теле, когда вы отправляете запрос «GET».
Утверждение, что «GET» предназначен только для получения данных, а «POST» для публикации данных, абсолютно неверно. Никто не может запретить вам создавать новый контент, удалять существующий контент, редактировать существующий контент или делать что-либо в бэкэнде, основываясь на данных, которые отправляются запросом «GET» или запросом «POST». И никто не может помешать вам закодировать бэкэнд так, чтобы с помощью запроса «POST» клиент запрашивал некоторые данные.
С помощью запроса, независимо от того, какой метод вы используете, вы вызываете URL и отправляете или не отправляете некоторые данные, чтобы указать, какую информацию вы хотите передать на сервер для обработки вашего запроса, и тогда клиент получает ответ от сервер. Данные могут содержать все, что вы хотите отправить, бэкэнд может делать с данными все, что он хочет, и ответ может содержать любую информацию, которую вы хотите поместить туда.
Есть только эти два ОСНОВНЫХ МЕТОДА. ПОЛУЧИТЬ и ПОСТ. Но это их структура, которая отличает их, а не то, что вы кодируете в бэкэнде. В бэкэнде вы можете кодировать все, что захотите, с полученными данными. Но с запросом "POST" вы должны отправлять / извлекать данные в теле, а не в строке URL-адреса, а с помощью запроса "GET" вы должны отправлять / извлекать данные в строке URL-адреса, а не в тело. Это все.
Все остальные методы, такие как «PUT», «DELETE» и т. Д., Имеют ту же структуру, что и «POST».
Метод POST в основном используется, если вы хотите несколько скрыть содержимое, потому что все, что вы пишете в строке URL-адреса, будет сохранено в кеше, а метод GET аналогичен написанию строки URL-адреса с данными. Поэтому, если вы хотите отправить конфиденциальные данные, которые не всегда являются именем пользователя и паролем, но, например, некоторые идентификаторы или хэши, которые вы не хотите отображать в строке url-address, вам следует использовать метод POST ,
Также длина URL-адресной строки ограничена 1024 символами, тогда как метод «POST» не ограничен. Поэтому, если у вас есть больший объем данных, вы не сможете отправить его с помощью GET-запроса, но вам нужно будет использовать POST-запрос. Так что это еще один плюс для POST-запроса.
Но иметь дело с GET-запросом намного проще, когда у вас нет сложного текста для отправки. В противном случае, и это еще один плюс для метода POST, это то, что с GET-методом вам нужно url-кодировать текст, чтобы иметь возможность посылать некоторые символы внутри текста или даже пробелы. Но с помощью метода POST у вас нет никаких ограничений, и ваш контент не нужно ни изменять, ни манипулировать.
И PUT, и POST являются методами отдыха.
PUT - если мы сделаем один и тот же запрос дважды, используя PUT, используя оба параметра одинаково, второй запрос не будет иметь никакого эффекта. Вот почему PUT обычно используется для сценария обновления, так как вызов Update более одного раза с одними и теми же параметрами не делает ничего, кроме первоначального вызова, следовательно, PUT является идемпотентным.
POST не идемпотентен, например, Create создаст две отдельные записи в цели, следовательно, он не идемпотентен, поэтому CREATE широко используется в POST.
Выполнение одного и того же вызова с использованием POST с одинаковыми параметрами каждый раз вызовет две разные вещи, поэтому POST обычно используется для сценария Create