Схема функционирования HTTP-сообщений и возможные риски. Типы HTTP-запросов и философия REST Пример между PUT и PATCH

При разработке процедуры отправки на сайт информации из 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, проверял ради спортивного интереса.

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

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

В этой статье мы рассмотрим структуру HTTP-сообщений и проанализируем, что происходит за кадром при просмотре веб-страниц.

Протокол HTTP используется в мировой паутине для обеспечения информационных транзакций между клиентом и сервером. На данный момент широко распространена версия HTTP/1.1, однако мировая индустрия вскоре начнет переходить на версию 2.0. Веб-сайты и веб-приложения являются тем, на чем построена всемирная паутина, однако между этими двумя сущностями есть ключевое различие, которое заключается в том, что веб-приложения принимают данные от пользователей. Веб-сайт может быть статическим, а веб-приложение обязательно должно быть динамическим. Веб-сайт хранит содержимое на веб-сервере, и ресурсы веб-сервера могут быть получены клиентами, однако сами ресурсы остаются неизменными. С другой стороны, веб приложение принимает данные от пользователя и динамически генерирует выходные сведения на базе того, что введено. В самом начале мировая паутина состояла только из веб-сайтов. Постепенно сайтов становилось все меньше, веб-приложения стали занимать более доминантную позицию.

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

HTTP-запросы

Простой HTTP-запрос:

Рисунок 1: Элементарный HTTP-запрос

GET – HTTP-метод

/ - Путь к ресурсу

HTTP/1.1 – Версия протокола HTTP

HTTP-методы:

Протокол HTTP поддерживает несколько методов. В самой первой версии HTTP/1.0 было три метода: GET, POST и HEAD. В HTTP/1.1 появилось несколько новых методов (см. RFC 2616): OPTIONS, CONNECT, TRACE, PUT и DELETE. В RFC 5789, появившегося в 2010 году, добавился метод PATCH.

Рисунок 2: Перечень методов, поддерживаемых протоколом HTTP/1.1

GET используется для простого запроса ресурсов с веб-сервера. Параметры для этого метода передаются через URL.

POST используется для отсылки данных на веб-сервер через тело HTTP-запроса.

HEAD схож с методом GET, но выводит только заголовки HTTP-ответа, который возвращает сервер.

OPTIONS используется для получения списка методов, принимаемых веб-сервером, которые хранятся в заголовке ‘Allow’ в HTTP-ответе.

PUT предназначен для замены существующего или создания нового ресурса на веб-сервере.

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

PATCH схож с методом PUT. Отличие заключается в этом, что PATCH поддерживает частичную модификацию, в то время как метод PUT поддерживает только полную замену ресурса.

Примечание:

В большинстве приложений используются в основном GET и POST, поскольку HTML поддерживает только эти два метода. Если предполагается использование методов OPTIONS, PUT, DELETE, PATCH, TRACE или CONNECT, необходимо все тщательно продумать и оценить риски в отношении приложения или веб-сервера.

URL или Uniform Resource Locator (унифицированный указатель ресурсов) является подмножеством унифицированных идентификаторов ресурсов (Uniform Resource Identifiers; URI). Типичная структура URL выглядит так:

:///?&

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

Рисунок 3: Переменная HOST представляет собой сетевой адрес веб-сервера, куда клиент отсылает HTTP-запрос

Рисунок 4: Наиболее распространенные заголовки HTTP-запроса

User-Agent содержит информацию о браузере.

Accept определяет тип содержимого, который может принять клиент.

Accept-Encoding определяет тип кодировки, которую может принять клиент.

Content-Length определяет длину тела запроса в октетах. Это значение не имеет особой важности, но некоторые HTTP-методы (например, PUT) требуют этот заголовок. Если необходимо, в значение этого заголовка можно установить 0.
Referer содержит URL-источник запроса.

Cookie предназначен для отправки cookies на сервер для управления сессией.

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

Authorization содержит информацию, имеющую отношение к аутентификации на конкретной платформе.

HTTP-ответы

Пример простого HTTP-ответа:

Рисунок 5: Элементарный HTTP-ответ

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

Рисунок 6: Перечень кодов статуса

Код ответа «100 Continue» редко когда-либо используется. Наиболее распространенный код «200 OK», который сигнализирует о том, что запрос корректен, ресурс существует, сервер обработал запрос и вернул ресурс в теле ответа. Код 201 означает, что ресурс, запрашиваемый в запросе, был успешно создан. Этот код обычно является результатом запроса с использованием метода PUT. Коды статуса 3xx возвращается приложениями со ссылкой на ресурс, куда нужно перенаправить клиента. Ссылка находится либо в тебе ответа, либо в заголовке «location». Коды статуса 4xx отсылаются в случае, если запрашиваемого ресурса на сервере не существует или пользователь не авторизован для получения содержимого или при возникновении ошибки в запросе, отправленном серверу. Коды статуса 5xx возвращаются в случае, когда сервере возникает ошибка, и нет возможности обработать запрос.

Рисунок 7: Наиболее распространенные HTTP-заголовки ответов

Date содержит дату, когда получен запрос.

Server содержит информацию о веб-сервере (например, IIS/Apache).

X-Powered-By содержит информацию, касающуюся технологии, используемой в скриптах, и текущую версию (например, PHP или Asp.net).

Content-Length схож с аналогичным заголовком в запросе. Содержит длину тела ответа в октетах.

Set-Cookie содержит cookie, используемые клиентом при формировании запроса с целью управления сессией.

Expires содержит, время по истечению которого сервер не будет рассматривать ответ как корректный.

Cache-Control указывает клиенту, нужно ли кэшировать возвращаемые запросы.

Пример HTTP-запроса с использованием метода GET:

Рисунок 8: Пример использования метода GET

Как видно на рисунке выше, в первой строчке указан метод, путь к ресурсу с параметрами и используемая версия HTTP. Во второй строчке указан хост, которому посылается запрос. В третьей строке содержится информация о браузере клиента. В четвертной строчке указан тип данных, который может принимать клиент. В пятой строчке указан язык, используемый клиентом. В шестой – cookie, полученные с сервера для поддержания сессии. Седьмая строчка указывает, нужно ли закрывать сессию или оставить открытой. Последняя строчка нужна при использовании метода GET и является пустой.

Пример ответа на запрос с использованием метода GET:

Рисунок 9: Ответ на запрос с использованием метода GET

В ответе на запрос содержится несколько HTTP-заголовков, которые уже обсуждались ранее.

Пример использования метода POST:

Рисунок 10: Пример отправки информации методом POST

HTTP-запрос с использованием метода POST во многом схож с запросом с методом GET, который мы только что рассматривали. Основное отличие заключается в том, что параметры передаются не через URL, а через тело запроса. Этот метод более безопасен и пригоден для передачи конфиденциальной информации, поскольку передаваемые сведения нельзя получить из кэша на стороне клиента. Если планируется передавать параметры, имеющие отношение к аутентификации, следует использовать протокол HTTPS вместе с TLS с целью включения функции шифрования передаваемой информации. Заголовок Content-Length содержит длину тела запроса в октетах. И, наконец, заголовок Referer указывает серверу место возникновения запроса.

Пример HTTP-запроса с методом TRACE:

TRACE:

Рисунок 12: Ответ на запрос с методом TRACE

Как видно из рисунка выше, при использовании метода TRACE сервер возвращает в теле ответа все, что было отправлено в запросе. Эта функция может быть полезна в том случае, если клиенту нужно точно знать, что получено сервером. Метод TRACK выполняет ту же самую функцию, но используется при работе с сервером Microsoft IIS. Уязвимости, которые могут возникать при использовании метода TRACE, связаны с межсайтовой трассировкой (Cross-Site Tracing; XST). Этот класс брешей злоумышленник может использовать для кражи cookie или другой конфиденциальной информации (например, учетных записей), хранимых в заголовке Authorization при помощи межсайтового скриптинга (XSS).

Пример HTTP-запроса с методом PUT:

Рисунок 13: Создание простейшей страницы при помощи метода PUT

Метод PUT требует использования в запросе заголовка Content-Length. Значение этого заголовка особого значение не имеет и может быть установлено нулевым без каких-либо непредсказуемых последствий. Если директория, указанная в URL, уже существует на сервере, соответствующий ресурс будет полностью заменен. Если ресурса, указанного в URL, не существует, то будет создан новый ресурс (предполагается, что соответствующий метод реализован на сервере). Содержимое ресурса, который нужно создать, указывается в теле запроса. В примере выше создается простая html-страница.

Пример ответа на запрос с методом PUT:

Рисунок 14: Ответ с кодом об успешном создании страницы

В идеале от сервера должен прийти ответ с кодом статуса «201 Created», свидетельствующий о том, что ресурс создан. Кроме того, в HTTP-запрос можно было бы вставить заголовок «Expect: 100-continue», чтобы удостовериться, что сервер готов к обработке и не закроет сокет до того, как получит содержимое, которое вы указали в теле запроса. При использовании в запросе заголовка «Expect» в ответ может прийти один из двух кодов статуса: «100 Continue» или «417 Expectation Failed».

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

Пример атаки показан на рисунке ниже. В этом примере в тело HTTP-запроса вставляется код шелла, который, в случае принятия запроса сервером, позволяет злоумышленнику выполнять команды.

Пример HTTP-запроса с методом PUT и вставкой кода шелла:

Рисунок 15: Пример использования кода шелла в теле запроса

Пример HTTP-запроса с методом DELETE:

Рисунок 15: Запрос на удаление ресурса при помощи метода DELETE

Пример ответа на запрос с методом DELETE:

Рисунок 16: Ответ на запрос об успешном удалении ресурса

После успешного удаления ресурса, указанного в URL, сервер должен вернуть код статуса 200 OK.

Пример HTTP-запроса с методом OPTIONS:

Пример ответа на запрос с методом OPTIONS:

Рисунок 18: Ответ с перечнем методов, доступных на сервере

Цель метода OPTIONS – узнать, какие методы разрешены на сервере. При помощи этого метода нельзя нанести какой-либо ущерб, а только собрать нужную информацию. Важно отметить, что содержимое заголовка «Allow» в заголовке ответа часто содержит методы, разрешенные не на сервере, а на прокси-сервере в случае, если трафик проходит через туннель.

В данной статье была представлена информация относительно использования HTTP-сообщений и методов, реализованных в протоколе HTTP/1.1. Кроме того, затрагивалась информация о возможных сценариях атак против веб-приложений при помощи этих методов. Эти сведения могут помочь вам в разработке сценариев пентестов. Надеемся, что после ознакомления с этой заметкой, вы стали лучше понимать механизмы функционирования и потоков данных протокола HTTP.

Все данные в рамках Web-технологии передаются по протоколу HTTР . Исключение составляет обмен с использованием программирования на Java или обмен из Plugin-приложений. Учитывая реальный объем трафика, который передается в рамках Web-обмена по HTTP , мы будем рассматривать только этот протокол. При этом мы остановимся на таких вопросах, как:

общая структура сообщений;
методы доступа;
оптимизация обменов.

Общая структура сообщений

HTTP - это протокол прикладного уровня. Он ориентирован на модель обмена "клиент-сервер". Клиент и сервер обмениваются фрагментами данных, которые называются HTTP-сообщениями. Сообщения, отправляемые клиентом серверу, называют запросами, а сообщения, отправляемые сервером клиенту - откликами. Сообщение может состоять из двух частей: заголовка и тела. Тело от заголовка отделяется пустой строкой.

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

Тело сообщения не является обязательным, в отличие от заголовка сообщения. Оно может содержать текст, графику, аудио- или видеоинформацию.

Ниже приведен HTTP-запрос:

GET / HTTP/1.0 Accept: image/jpeg пустая строка

И отклик:

HTTP/1.0 200 OK Date: Fri, 24 Jul 1998 21:30:51 GMT Server: Apache/1.2.5 Content-type: text/html Content-length: 21345 пустая строка ...

Текст "пустая строка" - это просто обозначение наличия пустой строки, которая отделяет заголовок HTTP-сообщения от его тела.

Сервер, принимая запрос от клиента, часть информации заголовка HTTP-запроса преобразует в переменные окружения, которые доступны для анализа CGI-скриптом . Если запрос имеет тело, то оно становится доступным скрипту через поток стандартного ввода.

Методы доступа

Самой главной директивой HTTP-запроса является метод доступа. Он указывается первым словом в первой строке запроса. В нашем примере это GET . Различают четыре основных метода доступа:

HEAD;
POST;

Кроме этих четырех методов существует еще около пяти дополнительных методов доступа, но они используются редко.

Метод GET

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

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

Метод HEAD

Метод HEAD используется для уменьшения обменов при работе по протоколу HTTP . Он аналогичен методу GET за исключением того, что в отклике тело сообщения не передается. Данный метод используется для проверки времени последней модификации ресурса и срока годности кэшированных ресурсов, а также при использовании программ сканирования ресурсов World Wide Web. Одним словом, метод HEAD предназначен для уменьшения объема передаваемой по сети информации в рамках HTTP-обмена.

Метод POST

Метод POST - это альтернатива методу GET . При обмене данными по методу POST в запросе клиента присутствует тело HTTP-сообщения. Это тело может формироваться из данных, которые вводятся в HTML-форме, или из присоединенного внешнего файла. В отклике, как правило, присутствует и заголовок, и тело HTTP-сообщения. Чтобы инициировать обмен по методу POST , в атрибуте METHOD контейнера FORM следует указать значение " post ".

Метод PUT

Метод PUT используется для публикации HTML-страниц в каталоге HTTP-сервера. При передаче данных от клиента к серверу в сообщении присутствует и заголовок сообщения, в котором указан URL данного ресурса, и тело - содержание размещаемого ресурса.

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

Оптимизация обменов

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

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

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

Для оптимизации числа открытых TCP-соединений в HTTP-протоколе версий 1.0 и 1.1 предусмотрен режим keep-alive. В этом режиме соединение инициализируется только один раз, и по нему последовательно можно реализовать несколько HTTP-обменов.

Для обеспечения поддержки сессий к директивам HTTP-заголовка были добавлены "печенюшки" (cookies). Они позволяют сымитировать поддержку соединения при работе по протоколу HTTP .

Виды интерфейса пользователя в Web-технологии

Страницы World Wide Web по функциональному назначению можно разделить на несколько типов: информационные страницы, навигационные страницы, страницы обмена данными. Во многих случаях эти функции можно объединить в одной странице.

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

Навигационные страницы - это совокупность гипертекстовых ссылок, которая позволяет ориентироваться в материалах Web-узла. Типичный пример такой страницы - Home page (домашняя страница). Как правило, на ней нет пространных текстовых описаний и иллюстраций, она состоит из совокупности различных меню. Эти меню можно реализовать через списки, таблицы ссылок или imagemap.

Страницы обмена данными позволяют передать на сервер некоторый объем информации, отличный от стандартного адреса (URL) ресурса. При просмотре и навигации пользователь просто выбирает гипертекстовые ссылки, по которым загружаются новые страницы. При обмене данными на сервер передается не только адрес ресурса, но и дополнительная информация, которую вводит пользователь.

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

При этом формы обеспечивают практически все необходимые виды полей ввода и меню. Единственное, чего не позволяют реализовать HTML-формы, так это вложенные меню. Формы можно применять не только при обмене данными. Достаточно развитые механизмы обработки форм присутствуют в JavaScript.

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

PATCH

Метод HTTP.PATCH используется для частичных модификаций обновления ресурса, то есть дельта-обновления.

http patch method is like a UPDATE query in SQL which sets or updates selected columns only and not the whole row.

Пример. Вы можете использовать метод PATCH для обновления состояния заказа.

PATCH/api/users/40450236/order/10234557

Насколько я понимаю все это, то, если сравнить 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 - никакого вреда нет, только такты забираются;-)

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