в чем разница между post и put
Типы HTTP-запросов и философия REST
Этот пост — ответ на вопрос, заданный в комментарии к одной из моих статей.
В статье я хочу рассказать, что же из себя представляют HTTP-методы GET/POST/PUT/DELETE и другие, для чего они были придуманы и как их использовать в соответствии с REST.
Итак, что же представляет из себя один из основных протоколов интернета? Педантов отправлю к RFC2616, а остальным расскажу по-человечески 🙂
Этот протокол описывает взаимодействие между двумя компьютерами (клиентом и сервером), построенное на базе сообщений, называемых запрос (Request) и ответ (Response). Каждое сообщение состоит из трех частей: стартовая строка, заголовки и тело. При этом обязательной является только стартовая строка.
Стартовые строки для запроса и ответа имеют различный формат — нам интересна только стартовая строка запроса, которая выглядит так:
где METHOD — это как раз метод HTTP-запроса, URI — идентификатор ресурса, VERSION — версия протокола (на данный момент актуальна версия 1.1).
Заголовки — это набор пар имя-значение, разделенных двоеточием. В заголовках передается различная служебная информация: кодировка сообщения, название и версия браузера, адрес, с которого пришел клиент (Referrer) и так далее.
Тело сообщения — это, собственно, передаваемые данные. В ответе передаваемыми данными, как правило, является html-страница, которую запросил браузер, а в запросе, например, в теле сообщения передается содержимое файлов, загружаемых на сервер. Но как правило, тело сообщения в запросе вообще отсутствует.
Пример HTTP-взаимодействия
Первая строка — это строка запроса, остальные — заголовки; тело сообщения отсутствует
Ресурсы и методы
Вернемся к стартовой строке запроса и вспомним, что в ней присутствует такой параметр, как URI. Это расшифровывается, как Uniform Resource Identifier — единообразный идентификатор ресурса. Ресурс — это, как правило, файл на сервере (пример URI в данном случае ‘/styles.css’), но вообще ресурсом может являться и какой-либо абстрактный объект (‘/blogs/webdev/’ — указывает на блок «Веб-разработка», а не на конкретный файл).
Тип HTTP-запроса (также называемый HTTP-метод) указывает серверу на то, какое действие мы хотим произвести с ресурсом. Изначально (в начале 90-х) предполагалось, что клиент может хотеть от ресурса только одно — получить его, однако сейчас по протоколу HTTP можно создавать посты, редактировать профиль, удалять сообщения и многое другое. И эти действия сложно объединить термином «получение».
В игру вступает REST
REST (REpresentational State Transfer) — это термин был введен в 2000-м году Роем Филдингом (Roy Fielding) — одним из разработчиков протокола HTTP — в качестве названия группы принципов построения веб-приложений. Вообще REST охватывает более широкую область, нежели HTTP — его можно применять и в других сетях с другими протоколами. REST описывает принципы взаимодействия клиента и сервера, основанные на понятиях «ресурса» и «глагола» (можно понимать их как подлежащее и сказуемое). В случае HTTP ресурс определяется своим URI, а глагол — это HTTP-метод.
REST предлагает отказаться от использования одинаковых URI для разных ресурсов (то есть адреса двух разных статей вроде /index.php?article_id=10 и /index.php?article_id=20 — это не REST-way) и использовать разные HTTP-методы для разных действий. То есть веб-приложение, написанное с использованием REST подхода будет удалять ресурс при обращении к нему с HTTP-методом DELETE (разумеется, это не значит, что надо давать возможность удалить всё и вся, но любой запрос на удаление в приложении должен использовать HTTP-метод DELETE).
REST дает программистам возможность писать стандартизованные и чуть более красивые веб-приложения, чем раньше. Используя REST, URI для добавления нового юзера будет не /user.php?action=create (метод GET/POST), а просто /user.php (метод строго POST).
В итоге, совместив имеющуюся спецификацию HTTP и REST-подход наконец-то обретают смысл различные HTTP-методы. GET — возвращает ресурс, POST — создает новый, PUT — обновляет существующий, DELETE — удаляет.
Проблемы?
Да, есть небольшая проблема с применением REST на практике. Проблема эта называется HTML.
PUT/DELETE запросы можно отправлять посредством XMLHttpRequest, посредством обращения к серверу «вручную» (скажем, через curl или даже через telnet), но нельзя сделать HTML-форму, отправляющую полноценный PUT/DELETE-запрос.
Дело в том, спецификация HTML не позволяет создавать формы, отправляющие данные иначе, чем через GET или POST. Поэтому для нормальной работы с другими методами приходится имитировать их искусственно. Например, в Rack (механизм, на базе которого Ruby взаимодействует с веб-сервером; с применением Rack сделаны Rails, Merb и другие Ruby-фреймворки) в форму можно добавить hidden-поле с именем «_method», а в качестве значения указать название метода (например, «PUT») — в этом случае будет отправлен POST-запрос, но Rack сможет сделать вид, что получил PUT, а не POST.
Разница между PUT и POST
Разница между PUT и POST — это вопрос семантики. Коль скоро для операций используются разные глаголы, то и смысл у них должен быть разным.
Представьте, что ваш сервис оперирует понятиями блокнот (notebook) и запись (post). Один блокнот может содержать множество записей.
Для добавления новой записи в блокнот c идентификатором id вы будете использовать метод POST с URL mydomain/notebooks/id/. Ваш сервис, ориентируясь на метод POST, сам присвоит нужный идентификатор записи, добавит ее в блокнот и вернет вам URL созданной записи (для доступа к записи по GET или для удаления по DELETE). При этом хорошо бы вернуть клиенту URL созданной записи.
Допустим, запись с идентификатором post-id уже создана и доступна по URL mydomain/notebooks/id/posts/post-id. Но клиент (владелец записи) исправил в ней ошибку и хочет перезаписать ее. Для этого он использует метод PUT с URL mydomain/notebooks/id/posts/post-id и передает обновленную запись в теле запроса. Ваш сервис, ориентируясь на метод PUT удаляет старую запись и записывает новую, при этом она доступна по тому же URL.
Конечно, никто не мешает вам всегда использовать метод POST (например HTML 4 позволял использовать только методы GET и POST). Но все же стоит придерживаться рекомендаций в целях единообразной трактовки методов всеми разработчиками.
ПС: Проще говоря чтобы придерживаться архитектурного стиля RESTful API мы используем метод POST для добавления новой записи в ответ получаем уникальный ключ, с которым в последствии можем редактировать запись методом PUT, удалять методом DELETE и запрашивать методом GET.
Добавить комментарий Отменить ответ
Для отправки комментария вам необходимо авторизоваться.
Разница между PUT и POST
Введение
Этот вопрос возникает либо на собеседованиях либо при проектировании своего API.
Меня спрашивали как минимум один раз.
В этой статье вы можете изучить несколько версий ответа на этот вопрос.
1. Новизна
POST это отправка новых данных на сервер.
PUT вносит изменения в уже имеющуюся на сервере информацию.
2. Идемпотентность
Метод PUT должен быть идемпотентным, то есть несколько одинаковых PUT на один endpoint не меняют состояния API.
POST не обязан быть идемпотентным
3. Тело
Метод POST подразумевает, что Вы передаёте данные в теле запроса.
POST http://urn.su:8080 /resource1/eventslist
<
«itemID»:»AB45636″,
«groupNo»:»XZ100329″,
«weight»:1395.00,
«Distance»:385.40,
«Time»:»2017-01-01T11:20:36.000+0000″,
«delayed»:true
>
Метод PUT подразумевает, что Вы передаёте всё, что нужно в URL. Тела запроса нет.
PUT http://www.answerit.ru:8080 /api/order/
Аргумент против этой версии:
HTTP 1.1 допускает наличие тела вообще у всех запросов.
У GET, HEAD и DELETE семантика тела запроса не опеределена, поэтому тело игнорируется, а вот у PUT с этим всё в порядке.
В своей работе я постоянно встречаю PUT запросы с телом.
4. CRUD
PUT вписывается в CRUD и покрывает Create и Update. POST не вписывается в CRUD.
Налицо противоречие с 1 где создание новых данных приписывается POST.
Потренироваться отправлять запросы PUT и POST можно на странице моего учебника
Увидеть своими глазами
Резюме
Исходя из имеющейся информации разница между POST и PUT может меняться в зависимости от реализации серверной части.
В чем разница между post и put
HTTP определяет множество методов запроса, которые указывают, какое желаемое действие выполнится для данного ресурса. Несмотря на то, что их названия могут быть существительными, эти методы запроса иногда называются HTTP глаголами.
CRUD — (англ. create read update delete — «Создание чтение обновление удаление») сокращённое именование 4 базовых функций при работе с персистентными хранилищами данных — создание, чтение, редактирование и удаление.
| Операция | Операция в HTTP |
| Создание (Create) | POST |
| Чтение (Read) | GET |
| Редактирование (Update) | PUT или PATCH |
| Удаление (Delete) | DELETE |
Каждый реализует свою семантику, но каждая группа команд разделяет общие свойства: так, методы могут быть безопасными (не изменяют состояния сервера – GET, HEAD, OPTIONS), идемпотентными (возвращают один и тот же результат на идентичный запрос – GET, HEAD, PUT, DELETE) или кэшируемыми.
Методы HTTP запроса:
POST запрос.
Применяется для передачи пользовательских данных заданному ресурсу. Например, в блогах посетители обычно могут вводить свои комментарии к записям в HTML-форму, после чего они передаются серверу методом POST и он помещает их на страницу. При этом передаваемые данные (в примере с блогами — текст комментария) включаются в тело запроса. Аналогично с помощью метода POST обычно загружаются файлы на сервер. Сообщение ответа сервера на выполнение метода POST не кэшируется.
Отличие GET от POST
GET отсылает запрос на получение данных, POST отправляет данные. GET. Добавляется в закладки. Кэшируется. История остается в закладках браузера. Есть ограничения по по символам, так как данные передаются в URL, то должен ограничиваться в 2048 символах (мах строка символов в URL). По типу данных допускается использование только символов ASCII. Менее безопасный, так как передоваемые в URL данные, видны пользователю. Данные в URL доступны всем.
Разница между PUT и POST
Разница между PUT и POST состоит в том, что PUT является идемпотентным: повторное его применение дает тот же результат, что и при первом применении (то есть у метода нет побочных эффектов), тогда как повторный вызов одного и того же метода POST может иметь такие эффекты, как например, оформление одного и того же заказа несколько раз.
Все безопасные методы являются также идемпотентными, как и некоторые другие, но при этом небезопасные, такие как PUT или DELETE.
Структура HTTP запроса:
-строку запроса, в которой указывается версия HTTP протокола и HTTP метод запроса;
-ноль или несколько заголовков, разделенных между собой символом конца строки, в которых передаются другие HTTP праметры для успешного HTTP соединения;
-пустую строку, чтобы отделить служебную информацию от тела сообщения;
-необязательное тело сообщения.
Зачем нужны Header?
Для того чтобы компьютер мог понимать с каким ресурсом работать:
Заголовок-сущность Content-Type используется для того, чтобы определить MIME тип ресурса.
MIME тип:
Content-Type (text/html; charset=utf-8)
Клиент может установить Accept в application/json, если он запрашивает ответ в JSON.
И наоборот, когда отправляются данные, установленный Content-Type в application/xml говорит клиенту, что данные были отправлены в XML форме.
В чем разница между POST и PUT HTTP REQUEST?
Кажется, они оба посылают данные на сервер внутри тела, так что же отличает их?
HTTP PUT:
HTTP POST:
Официальный HTTP RFC определяет POST:
Разница между POST и PUT:
Сам RFC объясняет основное различие:
Кроме того, и более кратко, в разделе 4.3.4 RFC 7231 раздел PUT (выделение добавлено),
Метод PUT запрашивает, чтобы состояние целевого ресурса было created или replaced с состоянием, определенным представлением, заключенным в полезную нагрузку сообщения запроса.
Используя правильный метод, не связанный в стороне:
Одним из преимуществ REST ROA по сравнению с SOAP является то, что при использовании HTTP REST ROA он поощряет правильное использование глаголов / методов HTTP. Так, например, вы будете использовать PUT, только если вы хотите создать ресурс именно в этом месте. И вы никогда не будете использовать GET для создания или изменения ресурса.
PUT Предполагается, что HTTP принимает тело запроса, а затем сохраняет его в ресурсе, идентифицированном URI.
HTTP POST является более общим. Предполагается инициировать действие на сервере. Это может быть сохранение тела запроса в ресурсе, идентифицированном URI, или это может быть другой URI, или это может быть другое действие.
Чтобы привести примеры ресурсов в стиле REST:
«POST / books» с кучей информации о книге может создать новую книгу и ответить новым URL-адресом, идентифицирующим эту книгу: «/ books / 5».
«PUT / books / 5» должен будет либо создать новую книгу с идентификатором 5, либо заменить существующую книгу с идентификатором 5.
PUT предназначен как метод для «загрузки» материала в определенный URI или перезаписи того, что уже есть в этом URI.
Насколько я знаю, PUT в основном используется для обновления записей.
Другие уже опубликовали отличные ответы, я просто хотел добавить, что с большинством языков, сред и сценариев использования вы будете иметь дело с POST намного, гораздо чаще, чем с PUT. До такой степени, что PUT, DELETE и т. Д. В основном пустяковые вопросы.
В последнее время меня очень раздражает популярное заблуждение веб-разработчиков о том, что POST используется для создания ресурса, а PUT используется для его обновления / изменения.
Метод PUT запрашивает, чтобы вложенный объект был сохранен под предоставленным Request-URI.
Есть также удобный параграф, чтобы объяснить разницу между POST и PUT:
Здесь ничего не говорится о разнице между обновлением / созданием, потому что дело не в этом. Это о разнице между этим:
Поэтому, пожалуйста, остановите распространение этого популярного заблуждения. Читайте ваши RFC.
POST считается методом фабричного типа. Вы включаете в него данные для создания того, что вы хотите, и все, что находится на другом конце, знает, что с этим делать. PUT используется для обновления существующих данных по заданному URL-адресу или для создания чего-то нового, когда вы знаете, каким будет URI, а он еще не существует (в отличие от POST, который создает что-то и возвращает URL-адрес это при необходимости).
REST просит разработчиков использовать методы HTTP явно и в соответствии с определением протокола. Этот базовый принцип проектирования REST устанавливает взаимно-однозначное сопоставление между операциями создания, чтения, обновления и удаления (CRUD) и методами HTTP. Согласно этому отображению:
• Чтобы создать ресурс на сервере, используйте POST.
• Чтобы получить ресурс, используйте GET.
• Чтобы изменить состояние ресурса или обновить его, используйте PUT.
• Чтобы удалить или удалить ресурс, используйте DELETE.
Это должно быть довольно просто, когда использовать один или другой, но сложные формулировки являются источником путаницы для многих из нас.
Когда их использовать:
Используйте, PUT когда вы хотите изменить отдельный ресурс, который уже является частью коллекции ресурсов. PUT заменяет ресурс в полном объеме. Пример: PUT /resources/:resourceId
Sidenote: используйте, PATCH если вы хотите обновить часть ресурса.
В основном:
Пример:
GET / company / reports => Получить все отчеты
GET / company / reports /
POST / company / reports => Создать новый отчет
PUT / company / reports /
PATCH / company / reports /
DELETE / company / reports /
Разница между 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
Этот вызов может создать новую книгу и вернуть эту книгу URI
PUT используется для замены ресурса, если этот ресурс существует, просто обновите его, но если этот ресурс не существует, создайте его,
С PUT мы знаем идентификатор ресурса, но POST вернем новый идентификатор ресурса
Не REST-полное использование
POST используется для инициирования действия на стороне сервера, это действие может создавать или не создавать ресурс, но это действие будет иметь побочные эффекты, всегда что-то меняет на сервере
PUT используется для размещения или замены буквального содержимого по определенному URL
Еще одно отличие в стилях REST-ful и non-REST-ful
POST является неидемпотентной операцией: она вызовет некоторые изменения, если выполняется несколько раз с одним и тем же запросом.
PUT Идемпотентная операция: она не будет иметь побочных эффектов, если выполняется несколько раз с одним и тем же запросом.
Обычный запрос (куки отправляются): ( PUT не поддерживается значение атрибута)
Код на attackersite.com :
XHR-запрос (файлы cookie отправляются): ( PUT вызовет предварительный запрос, ответ которого не позволит браузеру запрашивать deleteUser страницу)
Простыми словами вы можете сказать:
1.HTTP Get: используется для получения одного или нескольких предметов.
2.HTTP сообщение: используется для создания элемента
3.HTTP Put: используется для обновления элемента
4.HTTP Patch: используется для частичного обновления элемента
5.HTTP Delete: используется для удаления элемента
Утверждение, что «GET» предназначен только для получения данных, а «POST» для публикации данных, абсолютно неверно. Никто не может запретить вам создавать новый контент, удалять существующий контент, редактировать существующий контент или делать что-либо в бэкэнде, основываясь на данных, которые отправляются запросом «GET» или запросом «POST». И никто не может помешать вам закодировать бэкэнд так, чтобы с помощью запроса «POST» клиент запрашивал некоторые данные.
С помощью запроса, независимо от того, какой метод вы используете, вы вызываете URL и отправляете или не отправляете некоторые данные, чтобы указать, какую информацию вы хотите передать на сервер для обработки вашего запроса, и тогда клиент получает ответ от сервер. Данные могут содержать все, что вы хотите отправить, бэкэнд может делать с данными все, что он хочет, и ответ может содержать любую информацию, которую вы хотите поместить туда.
Есть только эти два ОСНОВНЫХ МЕТОДА. ПОЛУЧИТЬ и ПОСТ. Но это их структура, которая отличает их, а не то, что вы кодируете в бэкэнде. В бэкэнде вы можете кодировать все, что захотите, с полученными данными. Но с запросом «POST» вы должны отправлять / извлекать данные в теле, а не в строке URL-адреса, а с помощью запроса «GET» вы должны отправлять / извлекать данные в строке URL-адреса, а не в тело. Это все.
Все остальные методы, такие как «PUT», «DELETE» и т. Д., Имеют ту же структуру, что и «POST».
Также длина URL-адресной строки ограничена 1024 символами, тогда как метод «POST» не ограничен. Поэтому, если у вас есть больший объем данных, вы не сможете отправить его с помощью GET-запроса, но вам нужно будет использовать POST-запрос. Так что это еще один плюс для POST-запроса.
Но иметь дело с GET-запросом намного проще, когда у вас нет сложного текста для отправки. В противном случае, и это еще один плюс для метода POST, это то, что с GET-методом вам нужно url-кодировать текст, чтобы иметь возможность посылать некоторые символы внутри текста или даже пробелы. Но с помощью метода POST у вас нет никаких ограничений, и ваш контент не нужно ни изменять, ни манипулировать.