Какой протокол уровня приложений использует такие типы сообщений как get put и post. Типы HTTP-запросов и философия REST. Как работает пример приложения

03.11.2019

Насколько я понимаю все это, то, если сравнить PUT и POST операциями в MySQL, то POST - это INSERT, а PUT - UPDATE or INSERT

Расмотрим на примере форума. В нём есть темы и сообщения. Мы делаем запросы в тему hello

POST /topic/hello?message = Здесь POST /topic/hello?message = был POST /topic/hello?message = Вася

Первый запрос создаст (INSERT ) тему hello с сообщением "Здесь", остальные два запроса тоже создадут (INSERT ) новые сообщения в теме. В результате у нас получится, что тема hello содержит: Здесь был Вася.

PUT /topic/hello?message = Здесь PUT /topic/hello?message = был PUT /topic/hello?message = Вася

Первый запрос создаст (INSERT ) тему hello с сообщением "Здесь", остальные два запроса обновят (UPDATE ) сообщение в теме. В результате у нас получится, что тема hello содержит: Вася.

Идемпотентность PUT здесь проявляется в том, что количество сообщений в базе при последующих операциях остаётся неизменным . Касательно ссылок - карта сайта будет оставаться неизменной. Будет обновляться лишь содержимое тем.

или: каждый запрос POST /article/hello будет создавать новую главу в статье hello. Первый запрос создаст саму статью.

каждый запрос PUT /article/hello будет обновлять ЕДИНСТВЕННУЮ главу в статье hello. Первый запрос создаст саму статью.

Вот, что нам должен возвращать GET, если мы делали POST

GET /topic/hello 201 Здесь был Вася

В этом случае у нас также будут доступны и эти URI

GET /topic/hello/1 201 Здесь GET /topic/hello/2 201 был GET /topic/hello/3 201 Вася

Вот, что нам должен вернуть GET, если мы делали PUT

GET /topic/hello 201 Вася

В этом случае у нас будет доступна только одна URI

GET /topic/hello/1 201 Вася GET /topic/hello/2 404 GET /topic/hello/3 404

EXAMPLE #2 Пример с пользователями.

POST /user/eugen?age=7 POST /user/eugen?age=10 POST /user/eugen?age=5

Создаст 3 пользователя с именем eugen и возрастом 7, 10, 5, соответственно.

PUT /user/eugen?age=7 PUT /user/eugen?age=10 PUT /user/eugen?age=5

Будет создан только один пользователь с именем eugen с возрастом 5

Другими словами: PUT обязан обновлять запись, если данные уже есть

Отсюда и Ваш пример String userId = this.request["USER_ID"]; с сохранением значения в переменной. Сколько раз вы бы не ложили (PUT ) значения в переменную - переменная всегда будет одна.

Отсюда родился EXAMPLE #3

Не знаю на сколько эта аналогия верна, но думаю это утверждение будет верно:

POST: push $variable, value; -- в итоге массив значений PUT: $variable = value; -- в итоге одно значение

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

Кстати, вот нашел хороший ресурс, по поводу безопасности и идемпотентности

При разработке процедуры отправки на сайт информации из 1С с версией платформы 8.3.9.2170 столкнулся с проблемой: разработчик сайта предоставил мне возможность записывать нужную информацию только при помощи HTTP запроса методом PUT.

Недолго думая, я набросал простенький код:

По результатам выполнения в соответствующей строке заказа покупателя на сайте должно было проставиться количество поступившего на склад товара.

Однако, как вы уже наверно поняли, ничего не произошло. После того как я убедился, что на сайте ошибок нет (путем отправки аналогичного запроса через плагин к Хрому), я запустил на своем локальном компьютере web-сервер и стал экспериментировать.

Сразу же выяснилась странная вещь: вышеприведенный код генерирует не PUT, а HEAD запрос!

В логах апача я увидел следующее:

127.0.0.1 - - "HEAD /api/order_items/93076?order_item=30 HTTP/1.1"

Я немного удивился (в руководстве ведь было черным по белому написано PUT), но не растерялся - можно ведь вызвать метод напрямую:

Соединение.ВызватьHTTPМетод("PUT",Запрос);

В логах то же самое:

127.0.0.1 - - "HEAD /api/order_items/93076?order_item=30 HTTP/1.1"

"Может быть я что-то не так делаю?" - задал я себе вопрос. Но в интернете и в мануалах не было никаких подсказок. Что ж, метод научного тыка еще никто не отменял. Для начала я попробовал сделать так:

Соединение.ВызватьHTTPМетод("фывфыв",Запрос);

В логах получил:

127.0.0.1 - - "?????? /api/order_items/93076?order_item=30 HTTP/1.1"

Любопытно, значит 1С заменяет конкретно метод PUT (чем же он 1С не угодил?).

После еще нескольких попыток я пришел к варианту:

Соединение.ВызватьHTTPМетод("PUT ",Запрос);

В логах получил:

127.0.0.1 - - "PUT /api/order_items/93076?order_item=30 HTTP/1.1"

И уже этот вариант отработал на сайте и все остались довольны.

Подсказал более корректное решение проблемы: необходимо задать тело запроса, любое, даже пустое. Например, сработает такой вариант:

Соединение = Новый HTTPСоединение("www.mysite.ru"); Заголовки = Новый Соответствие; Заголовки["Content-Type"] = "application/x-www-form-urlencoded"; Запрос = Новый HTTPЗапрос("/api/order_items/93076?order_item=30", Заголовки); Запрос.УстановитьТелоИзСтроки("", КодировкаТекста.UTF8, ИспользованиеByteOrderMark.НеИспользовать); Соединение.Записать(Запрос);

И уже совсем правильно, наверное, передавать в теле запроса сами значения параметров.

Вывод следующий: PUT запрос без тела платформа 1С считает ошибочным и заменяет метод на HEAD.

Любопытно что POST запрос без тела 1С никак не отслеживает и не превращает в GET, проверял ради спортивного интереса.

Как сказал бы всем известный Вовочка из знаменитого анекдота: "Где логика?".

Надеюсь кому-то моя публикация сбережет несколько часов жизни в поисках ответа. =)))

15 ответов

HTTP PUT:

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

HTTP POST:

POST отправляет данные в определенный URI и ожидает, что ресурс в этом URI обрабатывает запрос. Веб-сервер в этот момент может определить, что делать с данными в контексте указанного ресурса. Метод POST не idempotent , однако ответы POST могут быть кэшируемыми, если сервер устанавливает соответствующие заголовки Cache-Control и Expires.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В последнее время меня очень раздражает популярное заблуждение веб-разработчиков, что POST используется для создания ресурса, а PUT используется для обновления/изменения.

Если вы посмотрите на страницу 55 RFC 2616 ("Протокол передачи гипертекста - HTTP/1.1"), раздел 9.6 ("PUT"), вы увидите что PUT действительно для:

Метод PUT запрашивает, чтобы закрытый объект был сохранен в поставляемом Request-URI.

Theres также удобный абзац, чтобы объяснить разницу между 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.

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

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

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

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

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

HTTP (англ. HyperText Transfer Protocol - «протокол передачи гипертекста») - протокол прикладного уровня передачи данных (изначально - в виде гипертекстовых документов в формате HTML). Основой HTTP является технология «клиент-сервер», то есть предполагается существование потребителей (клиентов), которые инициируют соединение и посылают запрос, и поставщиков (серверов), которые ожидают соединения для получения запроса, производят необходимые действия и возвращают обратно сообщение с результатом. HTTP в настоящее время повсеместно используется во Всемирной паутине для получения информации с веб-сайтов.

HTTP используется также в качестве «транспорта» для других протоколов прикладного уровня, таких как SOAP, XML-RPC, WebDAV.

Основным объектом манипуляции в HTTP является ресурс, на который указывает URI (англ. Uniform Resource Identifier) в запросе клиента. Обычно такими ресурсами являются хранящиеся на сервере файлы, но ими могут быть логические объекты или что-то абстрактное. Особенностью протокола HTTP является возможность указать в запросе и ответе способ представления одного и того же ресурса по различным параметрам: формату, кодировке, языку и т. д. (В частности для этого используется HTTP-заголовок.) Именно благодаря возможности указания способа кодирования сообщения клиент и сервер могут обмениваться двоичными данными, хотя данный протокол является текстовым.

HTTP - протокол прикладного уровня, аналогичными ему являются FTP и SMTP. Обмен сообщениями идёт по обыкновенной схеме «запрос-ответ». Для идентификации ресурсов HTTP использует глобальные URI. В отличие от многих других протоколов, HTTP не сохраняет своего состояния. Это означает отсутствие сохранения промежуточного состояния между парами «запрос-ответ». Компоненты, использующие HTTP, могут самостоятельно осуществлять сохранение информации о состоянии, связанной с последними запросами и ответами (например, «куки» на стороне клиента, «сессии» на стороне сервера). Браузер, посылающий запросы, может отслеживать задержки ответов. Сервер может хранить IP-адреса и заголовки запросов последних клиентов. Однако сам протокол не осведомлён о предыдущих запросах и ответах, в нём не предусмотрена внутренняя поддержка состояния, к нему не предъявляются такие требования.

Преимущества

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

Простота. Протокол прост в реализации, что позволяет легко создавать клиентские приложения.

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

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

Структура протокола

Каждое HTTP-сообщение состоит из трёх частей, которые передаются в указанном порядке:

Стартовая строка (англ. Starting line) - определяет тип сообщения;

Заголовки (англ. Headers) - характеризуют тело сообщения, параметры передачи и прочие сведения;

Тело сообщения (англ. Message Body) - непосредственно данные сообщения. Обязательно должно отделяться от заголовков пустой строкой.

Заголовки и тело сообщения могут отсутствовать, но стартовая строка является обязательным элементом, так как указывает на тип запроса/ответа. Исключением является версия 0.9 протокола, у которой сообщение запроса содержит только стартовую строку, а сообщения ответа только тело сообщения.

Стартовая строка

Стартовые строки различаются для запроса и ответа. Строка запроса выглядит так:

GET URI - для версии протокола 0.9.

Метод URI HTTP/Версия - для остальных версий.

Метод (англ. Method) - название запроса, одно слово заглавными буквами. В версии HTTP 0.9 использовался только метод GET, список запросов для версии 1.1 представлен ниже.

URI определяет путь к запрашиваемому документу.

Версия (англ. Version) - пара разделённых точкой цифр. Например: 1.0

Стартовая строка ответа сервера имеет следующий формат: HTTP/Версия КодСостояния Пояснение , где:

Версия - пара разделённых точкой цифр как в запросе.

Код состояния (англ. Status Code) - три цифры. По коду состояния определяется дальнейшее содержимое сообщения и поведение клиента.

Пояснение (англ. Reason Phrase) - текстовое короткое пояснение к коду ответа для пользователя. Никак не влияет на сообщение и является необязательным.

Например, стартовая строка ответа сервера на предыдущий запрос может выглядеть так:

Методы

Метод HTTP (англ. HTTP Method) - последовательность из любых символов, кроме управляющих и разделителей, указывающая на основную операцию над ресурсом. Обычно метод представляет собой короткое английское слово, записанное заглавными буквами. Обратите внимание, что название метода чувствительно к регистру.

Каждый сервер обязан поддерживать как минимум методы GET и HEAD. Если сервер не распознал указанный клиентом метод, то он должен вернуть статус 501 (Not Implemented). Если серверу метод известен, но он неприменим к конкретному ресурсу, то возвращается сообщение с кодом 405 (Method Not Allowed). В обоих случаях серверу следует включить в сообщение ответа заголовок Allow со списком поддерживаемых методов.

Кроме методов GET и HEAD, часто применяется метод POST.

OPTIONS Используется для определения возможностей веб-сервера или параметров соединения для конкретного ресурса. В ответ серверу следует включить заголовок Allow со списком поддерживаемых методов. Также в заголовке ответа может включаться информация о поддерживаемых расширениях.

Предполагается, что запрос клиента может содержать тело сообщения для указания интересующих его сведений. Формат тела и порядок работы с ним в настоящий момент не определён. Сервер пока должен его игнорировать. Аналогичная ситуация и с телом в ответе сервера.

Для того, чтобы узнать возможности всего сервера, клиент должен указать в URI звёздочку - «*». Запросы «OPTIONS * HTTP/1.1» могут также применяться для проверки работоспособности сервера (аналогично «пингованию») и тестирования на предмет поддержки сервером протокола HTTP версии 1.1.

Результат выполнения этого метода не кэшируется.

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

Клиент может передавать параметры выполнения запроса в URI целевого ресурса после символа «?»:

GET /path/resource?param1=value1¶m2=value2 HTTP/1.1

Аналогичен методу GET, за исключением того, что в ответе сервера отсутствует тело. Запрос HEAD обычно применяется для извлечения метаданных, проверки наличия ресурса (валидация URL) и чтобы узнать, не изменился ли он с момента последнего обращения.

Заголовки ответа могут кэшироваться. При несовпадении метаданных ресурса с соответствующей информацией в кэше копия ресурса помечается как устаревшая.

Применяется для передачи пользовательских данных заданному ресурсу. Например, в блогах посетители обычно могут вводить свои комментарии к записям в HTML-форму, после чего они передаются серверу методом POST и он помещает их на страницу. При этом передаваемые данные (в примере с блогами - текст комментария) включаются в тело запроса. Аналогично с помощью метода POST обычно загружаются файлы на сервер.

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

При результате выполнения 200 (Ok) в тело ответа следует включить сообщение об итоге выполнения запроса. Если был создан ресурс, то серверу следует вернуть ответ 201 (Created) с указанием URI нового ресурса в заголовке Location.

Сообщение ответа сервера на выполнение метода POST не кэшируется.

Применяется для загрузки содержимого запроса на указанный в запросе URI. Если по заданному URI не существовало ресурса, то сервер создаёт его и возвращает статус 201 (Created). Если же был изменён ресурс, то сервер возвращает 200 (Ok) или 204 (No Content). Сервер не должен игнорировать некорректные заголовки Content-*, передаваемые клиентом вместе с сообщением. Если какой-то из этих заголовков не может быть распознан или не допустим при текущих условиях, то необходимо вернуть код ошибки 501 (Not Implemented).

Фундаментальное различие методов POST и PUT заключается в понимании предназначений URI ресурсов. Метод POST предполагает, что по указанному URI будет производиться обработка передаваемого клиентом содержимого. Используя PUT, клиент предполагает, что загружаемое содержимое соответствует находящемуся по данному URI ресурсу.

Сообщения ответов сервера на метод PUT не кэшируются.

Аналогично PUT, но применяется только к фрагменту ресурса.

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

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

Устанавливает связь указанного ресурса с другими.

Убирает связь указанного ресурса с другими.

Преобразует соединение запроса в прозрачный TCP/IP туннель, обычно чтобы содействовать установлению защищенного SSL соединения через нешифрованный прокси.

7 ответов

СООБЩЕНИЕ

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

ПОЛОЖИЛ

HTTP.PUT может использоваться, когда клиент отправляет данные на сервер, и клиент определяет URI для вновь созданного ресурса. Метод PUT запрашивает, чтобы вложенный объект был сохранен под предоставленным Request-URI. Если Request-URI ссылается на уже существующий ресурс, вложенный объект СЛЕДУЕТ рассматривать как модифицированную версию, находящуюся на исходном сервере. Если Request-URI не указывает на существующий ресурс, и этот URI может быть определен как новый ресурс запрашивающим пользовательским агентом, сервер-источник может создать ресурс с этим URI.

PATCH

HTTP.PATCH может использоваться, когда клиент отправляет одно или несколько изменений, которые будут применены сервером. Метод PATCH запрашивает, чтобы набор изменений, описанный в объекте запроса, был применен к ресурсу, идентифицированному Request-URI. Набор изменений представлен в формате, называемом патч-документ.

Для получения дополнительной информации обратитесь к указанному ниже URL

Разница между PUT, POST, GET, DELETE и PATCH IN HTTP Глаголы:

Наиболее часто используемые HTTP-глаголы POST, GET, PUT, DELETE аналогичны операциям CRUD (Create, Read, Update and Delete) в базе данных. Мы указываем эти HTTP-глаголы в случае с капиталом . Итак, ниже показано сравнение между ними.

create - POST
читать - GET
update - PUT
delete - DELETE

PATCH: Предоставляет частичную модификацию ресурса. Если вам нужно обновить только одно поле для ресурса, вы можете использовать метод PATCH.

Замечания:
Поскольку POST, PUT, DELETE изменяет содержимое, тесты с помощью скрипача для приведенного ниже URL просто подражают обновлениям. Он не удаляет и не изменяет фактически. Мы можем просто просмотреть коды состояния, чтобы проверить, не возникают ли вставки, обновления, удаления.

1) ПОЛУЧИТЬ:

GET - это самый простой способ HTTP-запроса; тот, который браузеры используют при каждом нажатии ссылки или введите URL-адрес в адресную строку. Он инструктирует сервер передавать данные, идентифицированные по URL-адресу клиенту. Данные не должны изменяться на стороне сервера в результате запроса GET. В этом смысле запрос GET доступен только для чтения.

Ответ: вы получите ответ как:

"userId": 1, "id": 1, "title": "sunt aut...", "body": "quia et suscipit..."

В пути "счастливый" (или без ошибок) GET возвращает представление в XML или JSON и код ответа HTTP 200 (OK). В случае ошибки он чаще всего возвращает 404 (NOT FOUND) или 400 (BAD REQUEST).

2) POST:

Глагол POST в основном используется для создания новых ресурсов. В частности, он использовал для создания подчиненных ресурсов. То есть подчиняется другому (например, родительскому) ресурсу.

При успешном создании возвращайте HTTP-статус 201, возвращая заголовок Location с ссылкой на вновь созданный ресурс с HTTP-статусом 201.

Проверка с помощью Fiddler или PostMan: мы можем использовать скрипач для проверки ответа. Откройте скрипт и выберите вкладку Compose. Укажите глагол и URL-адрес, как показано ниже, и нажмите "Выполнить", чтобы проверить ответ.

Тело запроса:

данные: {title: "foo", body: "bar", userId: 1000, Id: 1000}

Ответ. Вы получите код ответа 201.

Если мы хотим проверить вставленную запись с Id = 1000, измените глагол Get и используйте тот же url и нажмите Execute.

Как было сказано ранее, указанный выше URL-адрес позволяет читать только чтения (GET), мы не можем читать обновленные данные в реальном времени.

PUT чаще всего используется для возможностей обновления , PUT-ing к известному URI ресурса с телом запроса, содержащим обновленное представление исходного ресурса.

Тело запроса:

data: {title: "foo", body: "bar", userId: 1, Id: 1}

Ответ. При успешном обновлении он возвращает 200 (или 204, если не возвращает какой-либо контент в теле) из PUT.

4) УДАЛИТЬ:

DELETE довольно легко понять. Он используется для удаления ресурса, идентифицированного с помощью URI.

При успешном удалении возвращайте HTTP-статус 200 (OK) вместе с телом ответа, возможно, представление удаленного элемента (часто требует слишком большой полосы пропускания) или завернутый ответ (см. "Возвращаемые значения" ниже). Либо это, либо вернуть статус HTTP 204 (NO CONTENT) без тела ответа. Другими словами, рекомендуемый ответ - статус 204 без тела, или ответ типа JSEND и статус HTTP 200.

Глагол: УДАЛИТЬ

Ответ. При успешном удалении он возвращает статус HTTP 200 (OK) вместе с телом ответа.

Пример между PUT и PATCH

ПОЛОЖИЛ

Если мне пришлось изменить свое имя, то отправьте запрос PUT для обновления:

{"first": "Nazmul", "last": "hasan"} Итак, здесь, чтобы обновить первое имя, нам нужно снова отправить все параметры данных.

Патч-запрос говорит, что мы будем отправлять только данные, которые нам нужно изменить без изменения или воздействия на другие части данных. Пример: если нам нужно обновить только первое имя, мы передаем только первое имя.

Для получения дополнительной информации см. Ссылки ниже:

PUT = заменить ПОЛНЫЙ РЕСУРС новым представлением

PATCH = заменить части исходного ресурса на значения, предоставленные И | ИЛИ другие части ресурса обновлены, которые вы предоставили (временные метки) И | ИЛИ обновили ресурсные эффекты другими ресурсами (отношениями)

GET/PUT - идемпотентный патч иногда может быть идемпотентным

То, что является идемпотентом - это означает, что если мы запускаем запрос несколько раз, это не должно влиять на его результат (тот же результат. Предположим, что корова беременна, и если мы разводим ее снова, то она не может быть беременна несколько раз).

get: -

просто получить. Получить данные с сервера и показать их пользователю

post: -

создать новый ресурс в базе данных. Это означает, что он добавляет новые данные. Это не идемпотент.

put: -

Создать новый ресурс, иначе добавить к существующему. Идемпотент, потому что он будет обновлять один и тот же ресурс каждый раз, и результат будет одинаковым. ех. - исходные данные

{ id:1 name:parth email:[email protected] }

выполнить put-localhost/1 put email: [email protected]

{ id:1 email:[email protected] }

patch

так что теперь пришел патч, запрос PATCH может быть иногда идемпотентным

Id:1 name:parth email:[email protected] }

Название патча: W

{ id:1 name:w email:[email protected] } HTTP Method GET yes POST no PUT yes PATCH no* OPTIONS yes HEAD yes DELETE yes

Приведенное ниже определение взято из примера из реального мира.

Примерный обзор
Для каждой клиентской информации мы храним идентификатор, чтобы найти эти клиентские данные, и мы отправим этот идентификатор клиенту для справки.

СООБЩЕНИЕ
- Если Клиент отправляет данные без идентификатора с использованием метода POST, мы сохраняем их и назначаем новый идентификатор.
- Если Клиент снова отправляет те же данные без идентификатора с помощью метода POST, мы сохраняем их и назначаем новый идентификатор.
- Примечание : дублирование разрешено здесь
ПОЛОЖИЛ
- Если Клиент отправляет данные с идентификатором, мы проверим, существует ли этот идентификатор. Если идентификатор существует, мы обновим данные, в противном случае мы создадим его и назначим новый идентификатор.
- Если Клиент отправляет данные с идентификатором, мы проверим, существует ли этот идентификатор. Если идентификатор существует, мы обновим данные, иначе мы сгенерируем исключение.

Примечание. В методе Put мы не генерируем исключение, если идентификатор не найден. Но в методе Patch мы генерируем исключение, если идентификатор не найден.

Дайте мне знать, если у вас есть какие-либо вопросы по вышеуказанному.

Вот разница между методами POST, PUT и PATCH протокола HTTP.

POST

Метод HTTP.POST всегда создает новый ресурс на сервере. Его не-идемпотентный запрос, т.е. Если пользователь обращается к тем же запросам 2 раза, он создаст новый новый ресурс, если нет ограничений.

http post method is like a INSERT query in SQL which always creates a new record in database.

Пример. Используйте метод POST для сохранения нового пользователя, заказа и т.д., когда серверный сервер решает идентификатор ресурса для нового ресурса.

PUT

В методе HTTP.PUT ресурс сначала идентифицируется из URL-адреса, и если он существует, то он обновляется, иначе создается новый ресурс. Когда целевой ресурс существует, он перезаписывает этот ресурс с полным новым телом. Это метод HTTP.PUT используется для СОЗДАНИЯ или ОБНОВЛЕНИЯ ресурса.

http put method is like a MERGE query in SQL which inserts or updates a record depending upon whether the given record exists.

Запрос PUT является idempotent, т.е. удары одних и тех же запросов дважды будут обновлять существующую запись (новая запись не создается). В методе PUT идентификатор ресурса определяется клиентом и указан в URL-адресе запроса.

Пример. Используйте метод PUT для обновления существующего пользователя или заказа.