Метод put: PUT & POST при написании API — Хабр Q&A

7

автор: Stijn de Witt

Методы GET и POST. Использование и отличия

HTTP методы GET и POST используются для отправки данных на сервер.

Чаще всего методы используются в HTML формах, гиперссылках и AJAX запросах.

POST и GET запросы можно отправить на сервер с помощью любого программного обеспечения, работающего с протоколом HTTP.

Обработка запросов может отличаться в зависимости от типа сервера.

Большинство действующих сайтов работают с языком программирования PHP. В этом случае передаваемые данные попадают в суперглобальные массивы $_GET и $_POST.

Массивы $_GET и $_POST являются ассоциативными. Таким образом, переданный на сервер параметр с именем «user_name», будет доступен как $_GET[‘user_name’] или $_POST[‘user_name’] в зависимости от используемого метода.

Какой метод использовать GET или POST, чем отличаются методы

Основное отличие метода GET от POST в способе передачи данных.

Запрос GET передает данные в URL в виде пар «имя-значение» (другими словами, через ссылку), а запрос POST передает данные в теле запроса (подробно показано в примерах ниже). Это различие определяет свойства методов и ситуации, подходящие для использования того или иного HTTP метода.

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

Например, можно использовать метод GET в HTML форме фильтра товаров: когда нужно, исходя из данных введенных пользователем, переправить его на страницу с отфильтрованными товарами, соответствующими его выбору.

Запрос, выполненный методом POST, напротив следует использовать в случаях, когда нужно вносить изменение в ресурс (выполнить авторизацию, отправить форму оформления заказа, форму обратной связи, форму онлайн заявки). Повторный переход по конечной ссылке не вызовет повторную обработку запроса, так как не будет содержать переданных ранее параметров. Метод POST имеет большую степень защиты данных, чем GET: параметры запроса не видны пользователю без использования специального ПО, что дает методу преимущество при пересылке конфиденциальных данных, например в формах авторизации.

HTTP метод POST поддерживает тип кодирования данных multipart/form-data, что позволяет передавать файлы.

Также следует заметить, что методы можно комбинировать. То есть, при необходимости вы можете отправить POST запрос на URL, имеющий GET параметры.

В каких случаях использовать POST и когда нужно использовать GET

В таблице ниже показаны распространенные варианты использования HTTP запросов с объяснением в чем разница между GET и POST запросами в конкретной ситуации.

Сравнительная таблица HTTP методов GET и POST

В таблице ниже приведены основные свойства и отличия GET и POST методов.

Пример использования GET запроса

В примере показана простая HTML форма фильтра по нескольким параметрам.

HTML код формы, генерирующей GET запрос:

<form method="GET" name="filter" action="http://example.com/catalog/">
<p>Диагональ экрана</p>
<label><input type="radio" name="screen" value="4" checked> 4</label><br>
<label><input type="radio" name="screen" value="4.5"> 4.5</label><br>
<label><input type="radio" name="screen" value="5"> 5</label>
<p>Цвет</p>
<label><input type="checkbox" name="color_black" checked> Черный</label><br>
<label><input type="checkbox" name="color_white" checked> Белый</label><br>
<label><input type="checkbox" name="color_golden"> Золотой</label><br>
<input type="submit" value="Применить фильтр">
</form>

После отправки формы браузер переведет пользователя по ссылке:

http://example.com/catalog/?screen=4&color_black=on&color_white=on

Ссылка содержит URL документа, отвечающего за обработку и блок параметров. Знак «?» отмечает начало блока параметров GET запроса. Далее находятся пары «имя-значение», разделенные знаком «&». Имена параметров отделены от значений знаком «=».

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

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

В примере показана простая HTML форма авторизации.

HTML код формы, генерирующей POST запрос:

<form method="POST" name="authorization" action="http://example.com/profile.php">
Логин: <input type="text" name="username"><br>
Пароль: <input type="password" name="user_password"><br>
<input type="submit" value="Войти">
</form>

После отправки формы браузер переведет пользователя по ссылке:

http://example.com/profile.php

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

Запрос состоит из области заголовков и тела запроса.

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

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

16 Http. Методы get, head, post, put delete, trace.

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/1.0 200 OK

Методы

Метод 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

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

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

GET /path/resource?param1=value1&param2=value2 HTTP/1.1

HEAD

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

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

POST

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

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

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

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

PUT

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

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

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

PATCH

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

DELETE

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

TRACE

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

LINK

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

UNLINK

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

CONNECT

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

Методы передачи данных GET и POST, DELETE, PUT. REST архите…

Привет, сегодня поговорим про методы передачи данных, обещаю рассказать все что знаю. Для того чтобы лучше понимать что такое методы передачи данных, crud, rest архитектура, cgi приложения,rest api,hateoas , настоятельно рекомендую прочитать все из категории Выполнение скриптов на стороне сервера PHP (LAMP) NodeJS

REST — это стиль архитектуры программного обеспечения для построения распределенных масштабируемых веб-сервисов. Рой выступал за использование стандартных HTTP методов так, чтобы придавать запросам определенный смысл.

REST (сокр. от англ. Representational State Transfer — «передача состояния представления») — архитектурный стиль взаимодействия компонентов распределенного приложения в сети. REST представляет собой согласованный набор ограничений, учитываемых при проектировании распределенной гипермедиа-системы. В определенных случаях (интернет-магазины, поисковые системы, прочие системы, основанные на данных) это приводит к повышению производительности и упрощению архитектуры. В широком смысле компоненты в REST взаимодействуют наподобие взаимодействия клиентов и серверов во Всемирной паутине. REST является альтернативой RPC .

В сети Интернет вызов удаленной процедуры может представлять собой обычный HTTP- запрос (обычно «GET» или «POST»; такой запрос называют «REST-запрос»), а необходимые данные передаются в качестве параметров запроса

Для веб-служб, построенных с учетом REST (то есть не нарушающих накладываемых им ограничений), применяют термин «RESTful».

В отличие от веб-сервисов (веб-служб) на основе SOAP, не существует «официального» стандарта для RESTful веб-API. Дело в том, что REST является архитектурным стилем, в то время как SOAP является протоколом. Несмотря на то, что REST не является стандартом сам по себе, большинство RESTful-реализаций используют стандарты, такие как HTTP, URL, JSON и XML.

Рой Филдинг предложил использовать Web не только для общения между человеком и машиной, но и для общения между машинами.REST задуман так, что если правильно применять, то можно построить приложение (с API), которое будет работать и масштабироваться веками.. Здесь нет ни слова об API, HTTP или красивых URL. однако на практике расширяют это понятие на прмере api, url, методов.

Таким образом, данные HTTP-запросы будут иметь различный смысловую нагрузку в REST:

• GET /object/list — получение данных об объекте
• POST /object/list — созлание объекта из переданных данных
• PUT /object/list — обновление существующего объекта
• DELETE /object/list — удаление объекта

Выше только некоторые виды запросов, а вот весь их список: CONNECT, DELETE, GET, HEAD, OPTIONS, PATCH, POST, PUT, TRACE.

Итак, одна транзакция по RESTful API будет состоять, как минимум, из следующего:

• Метод запроса, например, GET
• Путь запроса, например, /object/list
• Тело запроса, например, форма
• Код ответа, например, 200 ОК
• Тело ответа, например, данные в формате JSON

Задумаемся на минуту, что же происходит, когда мы набираем в браузере строку somestring и нажимаем . Браузер посылает серверу запрос somestring? Нет, конечно. Все немного сложнее. Он анализирует строку, выделяет из нее имя сервера и порт (а также имя протокола, но нам это сейчас не интересно), устанавливает соединение с Web-сервером по адресу сервер:порт и посылает ему что-то вроде следующего:

GET somestring HTTP/1.0\n
…другая информация…
\n\n

Здесь \n означает символ перевода строки, а \n\n — два обязательных символа новой строки, которые являются маркером окончания запроса (точнее, окончания заголовков запроса). Пока мы не пошлем этот маркер, сервер не будет обрабатывать наш запрос.

Как видим, после GET-строки могут следовать и другие строки с информацией, разделенные символом перевода строки. Их обычно формирует браузер. Такие строки называются заголовками (headers), и их может быть сколько угодно. Протокол HTTP как раз и задает правила формирования и интерпретации этих заголовков. Вот мы и начинаем знакомство с протоколом HTTP. Как видите, он представляет собой ни что иное, как просто набор заголовков, которыми обмениваются сервер и браузер, и еще пару соглашений насчет метода POST, которые мы вскоре рассмотрим.
Не все заголовки обрабатываются сервером — некоторые просто пересылаются запускаемому сценарию с помощьюпеременных окружения.

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

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

Метод запроса GET

Формат запроса: GET сценарий?параметры HTTP/1.0

>>> Переменные окружения: REQUEST_URI; в переменной QUERY_STRING сохраняется значение и параметры, в переменной REQUEST_METHOD — ключевое слово GET.

Этот заголовок является обязательным (если только не применяется метод POST) и определяет адрес запрашиваемого документа на сервере. Также задаются параметры, которые пересылаются сценарию (если сценарию ничего не передается, или же это обычная статическая страница, то все символы после знака вопроса и сам знак опускаются). Вместо строки HTTP/1.0 может быть указан и другой протокол — например, HTTP/1.1. Именно его соглашения и будут учитываться сервером при обработке данных, поступивших от пользователя, и других заголовков.

Строка сценарий?параметры задается в том же самом формате, в котором она входит в URL. Неплохо было бы назвать эту строку как-нибудь более реалистично, чтобы учесть возможность присутствия в ней командных параметров. Такое название действительно существует и звучит как URI (Universal Resource Identifier — Универсальный идентификатор ресурса). Очень часто его смешивают с понятием URL (вплоть до того, что это происходит даже в официальной документации по стандартам HTTP). Под словом URL мы понимаем полный путь к некоторой Web-странице вместе с параметрами, а URI — это его часть, расположенная после имени (или IP-адреса) хоста и номера порта.

Метод запроса POST

Формат запроса: POST сценарий?параметры HTTP/1.0

>>> Переменная окружения: REQUEST_URI; в переменной QUERY_STRING сохраняется значение и параметры, в переменной REQUEST_METHOD — слово POST.

Настал момент рассмотреть метод POST. Приведем сразу практический пример метода запроса POST:

POST /script.cgi HTTP/1.0\n
Content-length: 6\n
\n
Hello!

Сервер начнет обработку запроса, не дожидаясь передачи данных после маркера конца заголовков. Иными словами, сценарий запустится сразу же после отправки \n\n, а уж ждать или не ждать, пока придет строка Hello! длиной 6 байт — его дело. Последнее означает, что сервер никак не интерпретирует POST-данные (точно так же, как он не интерпретирует некоторые заголовки), а пересылает их непосредственно сценарию. Но как же сценарий узнает, когда данные кончаются, т. е. когда ему прекращать чтение информации, поступившей от браузера? В этом ему поможет переменная окружения Content-Length, и именно на нее следует ориентироваться.

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

Архитектура REST описывается шестью ограничениями . Об этом говорит сайт https://intellect.icu . Эти ограничения, применительно к архитектуре, первоначально были представлены Роем Филдингом (Roy Fielding) в его докторской диссертации и определяют основы RESTful стиля.

Шесть ограничений:

• Единый интерфейс (Uniform Interface)

  Единый интерфейс определяет интерфейс между клиентами и серверами. Это упрощает и отделяет архитектуру, которая позволяет каждой части развиваться самостоятельно. Четыре принципа единого интерфейса:

  Основан на ресурсах

  Отдельные ресурсы определяются в запросе, для чего используется URI, как идентификаторы ресурсов. Сами ресурсы концептуально отделены от представлений, которые возвращаются клиенту. Например, сервер не отправляет свою базу данных, а, скорее, некоторые HTML, XML или JSON, которые представляет некоторые записи в базе данных, например, на финском языке и в UTF-8, в зависимости от деталей запроса и реализации сервера.

  Манипуляции над ресурсами через представления

  Когда пользователь имеет представление о ресурсе, в том числе о связанных метаданных, он имеет достаточно информации для изменения или удаления ресурса на сервере, если у него есть на это разрешение

  Само-документируемые сообщения

  Каждое сообщение содержит достаточно информации для описания того, как его выполнить. Например, вызываемый парсер может описываться с помощью Internet media type (так же известным как MIME) Ответы также явно указывают на их способность кешировать.

  Hypermedia as the Engine of Application State (HATEOAS)

  Клиенты предоставляют статус через содержимое body, параметры строки запроса, заголовки запросов и запрашиваемый URI (имя ресурса). Это называется гипермедиа (или гиперссылки с гипертекстом)

  Наряду с приведенным выше описанием, HATEOS также означает, что, в случае необходимости ссылки содержатся в теле ответа (или заголовках) для поддержки URI извлечения самого объекта или запрошенных объектов. Позднее, мы затронем эту тему глубже.

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

  Отсутствие состояний (Stateless)

• Так как REST это акроним для REpresentational State Transfer, отсутствие состояний является важной чертой. Таким образом, это значит, что необходимое состояние для обработки запроса содержится в самом запросе, либо в рамках URI, параметрах строки запроса, тела или заголовках. URI уникально идентифицирует ресурс и тело содержит состояние (или изменение состояния) этого ресурса. Затем, после того, как сервер завершит обработку, состояние или его часть(и) отдается обратно клиенту через заголовки, статус и тело ответа.

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

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

  Каждый встречал проблему с кнопкой «Назад» в своем веб приложении, когда оно ведет себя по разному в одной точке, потому что ожидались действия в определенном порядке? Такое происходит, когда нарушен принцип отсутствия состояний. Есть случаи, когда не соблюдается принцип отсутствия состояний, например, three-legged OAuth, ограничение скорости вызова API и т.д. Однако, приложите максимум усилий, чтобы состояние приложения не занимало несколько запросов к вашему сервису.

• Кеширование ответа (Cacheable)

  Как и в World Wide Web, клиент может кэшировать ответы. Таким образом, ответы явно или неявно определяют себя как кешируемые или нет, для предотвращения повторного использования клиентами устаревших или некорректных данных в ответ на дальнейшие запросы. Хорошо спроектированное кэширование частично или полностью устраняет некоторые клиент-серверные взаимодействия, способствуя дальнейшей масштабируемости и производительности.

• Клиент-сервер (Client-Server)

  Единый интерфейс отделяет клиентов от серверов. Разделение интерфейсов означает, что, например, клиенты не связаны с хранением данных, которое остается внутри каждого сервера, так что мобильность кода клиента улучшается. Серверы не связаны с интерфейсом пользователя или состоянием, так что серверы могут быть проще и масштабируемы. Серверы и клиенты могут быть заменяемы и разрабатываться независимо, пока интерфейс не изменяется.

• Многоуровневая система (Layered System)

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

• «Код по требованию» (Code on Demand — опционально)

• Серверы могут временно расширять или кастомизировать функционал клиента, передавая ему логику, которую он может исполнять. Например, это могут быть скомпилированные Java-апплеты или клиентские скрипты на Javascript

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

• , мы позволяем распределенной системе любого типа иметь такие свойства как: производительность, расширяемость, простота, обновляемость, понятность, портативность и надежность .

  Замечание Единственным необязательным ограничением для RESTful архитектуры — это «код по требованию». Если сервис не проходит по любым другим условиям, то его совершенно точно нельзя назвать RESTful.

Существует 2 основных типа ресурса в архитектуре REST: коллекция и элемент коллекции .

Коллекция представляет собой набор самостоятельных и самодостаточных элементов.

Пример ссылки на коллекцию пользователей:

/api/users

Элемент коллекции пользователей, или конкретный пользователь, в таком случае, может быть представлен в виде:

/api/users/ae25b8

Существительные — хорошо, глаголы — плохо.

Имена коллекций должны представлять сущности (существительные во множественном числе), и они должны быть максимально конкретными и понятными (самодокументирующимися). Если речь идет о собаках, то это должны быть собаки, а не просто животные.

Каждым ресурсом в RESTful API управляет несколько определенных минимально необходимых глаголов. Для большинства случаев достаточно 4 основных глагола (HTTP метода):

GET — получить

POST — создать

PUT — изменить

DELETE — удалить

GET, PUT, DELETE — идемпотентны.

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

Связи.

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

Коллекция машин пользователя:

/api/users/ae43bc/cars

Конкретная машина:

/api/users/ae43bc/cars

Не стоит писать длинные адреса — это плохо:

/api/users/ae43bc/cars/c7b45e/door/346ec3b

Такие адреса нелегко читать и искать в документации, часто это вообще не имеет смысла — идентификаторы уникальные и «/cars/c7b45e» абсолютно однозначно относится к «/users/ae43bc». Данный вариант следует сократить:

/api/cars/c7b45e/door/346ec3b

Ошибки.

Следует различать 2 основных семейства статус кодов (HTTP Status Code):

4xx — проблема возникла на стороне пользователя и он сам может ее исправить, правильно введя необходимую для запроса информацию.

5xx — проблема возникла на сервере и для ее решения пользователь может отправить запрос к службе поддержки.

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

Пример хорошо написанного ответа на ошибку:

HTTP Status Code: 401

{«status»: 401, «message»: «Authentication Required», «code»: 20003, «more_info»: «http://www.example.com/docs/errors/20003»}

Помните! Вы пишете API для таких же разработчиков как и Вы.

Используйте необходимый минимум статус кодов в приложении.

Иногда может быть достаточно 3:

1. 200 OK

2. 400 Bad Request (некорректный запрос)

3. 500 Internal Server Error (внутренняя ошибка сервера)

Если мало, дополняйте по мере необходимости:

1. 201 Created (успешно создан)

2. 304 Not Modified (данные не изменились)

3. 404 Not Found (не найден)

4. 401 Unauthorized (не авторизован)

5. 403 Forbidden (доступ запрещен)

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

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

PUT /api/users/de840a?supress_status_code=200

Это добавит нелишней гибкости Вашему API.

Версионность.

Обязательно указывайте номер версии, даже если не планируете изменение интерфейса — все может быстро измениться.

Версию можно указать в строке адреса:

/api/v2/users/ae43bc

или в параметрах запроса:

/api/users/ae43bc?v=2

Нет смысла делать длинными названия версий, вставлять в них точки: v1.03

Версии интерфейса должны меняться максимально редко, в то время как внутреннюю логику работы API можно менять, как только появилась необходимость. В реальности настоящая версия API может быть, например, v2.034-beta2, но версия интерфейса, и, соответственно, представленная в адресе версия будет просто 2.

Постраничная выдача.

Любая коллекция, какой бы маленькой, по Вашему мнению, она не была должна отдаваться постранично. Определитесь с форматом выдачи коллекции, например, Content-Type: application/json {«data»:{}, «paging»: {«limit»: 50, «offset»: 0, «total»: 150}} старайтесь всегда использовать одинаковый формат во всех ответах приложения — облегчите жизнь и себе и разработчикам клиентского ПО.

Стоит выбрать какие-то дефолнные значения для параметров «limit», «offset», и, скорее всего, ограничивать максимальное значение для «limit».

Прячьте все сложные компоненты запроса за «?».

Если в Вашем GET запросе необходимо использовать различные фильтры — поместите их за знаком вопроса (в параметрах URL):

GET /api/users?limit=10&offset=4&age=30&height=160&weight=120

Отдавайте пользователю только то, что он хочет.

Позвольте клиенту получать только те поля в запросе, которые ему нужны:

GET /api/users/ae43bc?fields=fitst_name,last_name,age,gender,finger_count

Формат отдаваемых данных.

Не ограничивайтесь каким-то одним форматом. Сделайте опционально несколько, например, json и xml. Таким легким способом можно значительно упростить разработку для клиентов, и отпадет необходимость выбора чего-то одного. Формат возвращаемых данных можно описывать как в HTTP заголовках, так и в строке запроса:

ACCEPT: application/json

GET /api/users/ae43bc.json

И обязательно стоит выбрать какой-то формат по умолчанию.

Поиск.

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

GET /api/search?q=some+text+to+find

Опять же в зависимости от системы используемого поискового движка можно применять различные фильтры.

Какой-то локальный поиск, в пределах коллекции, можно осуществить и простыми фильтрами:

GET /api/users?q=some+users+to+find

Авторизация .

Используйте, по возможности, последнюю версию OAuth — OAuth 2.0 — эта система хорошо известна разработчикам, и хорошо себя зарекомендовала. Зачем выдумывать велосипед?

Документация .

Это один из самых важных аспектов хорошего API. Любой, кто, когда-либо сталкивался с написанием клиентских скриптов, со мной согласится. Часы, потраченные на хорошую документацию, с лихвой окупятся долгими месяцами работы службы поддержки. Фокус прост — опишите сжато и четко все получаемые и отдаваемые данные, а также назначение методов. Помните! Вы пишете для программистов. Не стоит описывать какие-то очевидные моменты. Приведите все отдаваемые статус коды; перечислите все принимаемые параметры опишите их, где необходимо; давайте ссылки на более подробный материал; приводите примеры получаемых данных, если это уместно, с их описанием.

Ссылки.

Старайтесь отдавать в ответах ссылки на все связанные ресурсы, если хотите соответствовать принципу HATEOAS, и называться RESTful. За это Вас будут очень любить разработчики клиентских программ — им не придется самим генерировать эти ссылки.

Теперь самое главное!

Фасад Паттерн для API.

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

Помните! Интерфейс API должен быть максимально простым и понятным, только так можно достичь счастья и гармонии.

Что означает HATEOAS?

Термин HATEOAS означает фразу «Hypermedia As The Engine Of Application State» (Гипермедиа как двигатель состояния приложения). Чтобы понять это глубже, нам сначала нужно понять значение гипермедиа. Взгляните на следующую веб-страницу:

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

• Нажатие на кнопки (зеленое «Clone» (Клонировать) или «Download» (Скачать)
• Нажатие на вкладки (например, для просмотра «Issues» (Проблемы))
• и еще несколько

Теперь давайте посмотрим, как ведут себя наши REST API:

Если вы посмотрите на типичный запрос GET к RESTful серверу, такой как этот:

Запрос GET localhost:8080/users получает набор данных трех пользователей в этом случае. Отправив запрос с помощью GET localhost:8080/users/1, вы получите сведения только о первом пользователе. Как правило, когда мы выполняем запрос REST, мы получаем только данные, а не какие-либо действия с ними. Вот где HATEOAS восполняет пробел. Запрос HATEOAS позволяет вам не только отправлять данные, но и указывать связанные действия:

Этот пример был в формате JSON. Формат XML для другого примера будет выглядеть примерно так:

Когда вы отправляете этот запрос для получения данных учетной записи, вы получаете оба:

• Номер счета и данные баланса
• Ссылки, которые обеспечивают действия, чтобы сделать депозит/снятие/перевод/закрытие

С HATEOAS запрос на REST ресурс дает мне как данные, так и действия, связанные с данными.

Зачем нам нужен HATEOAS?

Единственная самая важная причина для HATEOAS — слабая связь (loose coupling). Если потребителю службы REST необходимо жестко закодировать все URL-адреса ресурсов, он тесно связан с реализацией вашей службы. Вместо этого, если вы вернете URL-адреса, которые он может использовать для действий, он будет слабосвязанным. Нет строгой зависимости от структуры URI, так как она указана и используется в ответе. Несколько важных тем, связанных с HATEOAS:

HAL — язык гипертекстовых приложений

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

С HAL у вас есть несколько категорий представлений:

• Links (Ссылки): указано как комбинация
• Target (Цель) — указана в качестве URI
• Relation (Отношение) — имя
• Embedded Resources (Встроенные ресурсы): другие ресурсы, содержащиеся в данном REST ресурсе
• State (Состояние): фактические данные ресурса

Если вам довелось использовать Spring Framework для разработки REST сервиса, то Spring HATEOAS — хороший механизм для вашего сервиса.

См. также

Напиши свое отношение к методы передачи данных. Это меня вдохновит писать для тебя всё больше и больше интересного. Спасибо Надеюсь, что теперь ты понял что такое методы передачи данных, crud, rest архитектура, cgi приложения,rest api,hateoas и для чего все это нужно, а если не понял, или есть замечания, то нестесняся пиши или спрашивай в комментариях, с удовольствием отвечу. Для того чтобы глубже понять настоятелно рекомендую изучить комплексно всю информацию в категории Выполнение скриптов на стороне сервера PHP (LAMP) NodeJS

put-method — AWS CLI 1.18.195 Справочник по командам

{«_links»: {«curies»: [{«href»: «https://docs.aws.amazon.com/apigateway/latest/developerguide/restapi -integration- {rel} .html «,» name «:» integration «,» templated «: true}, {» href «:» https://docs.aws.amazon.com/apigateway/latest/developerguide/restapi -integration-response- {rel} .html «,» name «:» integrationresponse «,» templated «: true}],» self «: {» href «:» / restapis / uojnr9hd57 / resources / 0cjtch / methods / GET / integration «},» integration: delete «: {» href «:» / restapis / uojnr9hd57 / resources / 0cjtch / methods / GET / integration «},» integration: response «: {» href «:» / restapis / uojnr9hd57 / resources / 0cjtch / methods / GET / integration / answers / 200 «,» name «:» 200 «,» title «:» 200 «},» integration: update «: {» href «:» / restapis / uojnr9hd57 / resources / 0cjtch / methods / GET / integration «},» integrationresponse: put «: {» href «:» / restapis / uojnr9hd57 / resources / 0cjtch / methods / GET / integration / answers / {status_code} «,» templated «: true}}, «cacheKeyPa параметры «: [],» cacheNamespace «:» 0cjtch «,» credentials «:» arn: aws: iam :: 123456789012: role / apigAwsProxyRole «,» httpMethod «:» POST «,» passthroughBehavior «:» WHEN_NO_MATCH «,» requestTemplates «: {» application / json «:» {\ n \ «a \»: \ «$ input.params (‘operand1’) \ «, \ n \» b \ «: \» $ input.params (‘operand2’) \ «, \ n \» op \ «: \» $ input.params (‘operator’) \ «\ n}»}, «type»: «AWS», «uri»: «arn: aws: apigateway: us-west-2: lambda: path // 2015-03-31 / functions / arn: aws: лямбда: us-west-2: 123456789012: function: Calc / invocations «,» _embedded «: {» integration: answers «: {» _links «: {» self «: {» href «:» / restapis / uojnr9hd57 / resources / 0cjtch / methods / GET / integration / answers / 200 «,» name «:» 200 «,» title «:» 200 «},» integrationresponse: delete «: {» href «:» / restapis / uojnr9hd57 / resources / 0cjtch / methods / GET / integration / answers / 200 «},» integrationresponse: update «: {» href «:» / restapis / uojnr9hd57 / resources / 0cjtch / methods / GET / integration / response / 200 «}},» responseParameters «: {» метод.response.header.operator «:» integration.response.body.op «,» method.response.header.operand_2 «:» integration.response.body.b «,» method.response.header.operand_1 «:» integration. response.body.a «},» responseTemplates «: {» application / json «:» #set ($ res = $ input.path (‘$’)) \ n {\ n \ «result \»: \ «$ res.a, $ res.b, $ res.op => $ res.c \ «, \ n \» a \ «: \» $ res.a \ «, \ n \» b \ «: \» $ res.b \ «, \ n \» op \ «: \» $ res.op \ «, \ n \» c \ «: \» $ res.c \ «\ n}»}, «selectionPattern»: » «,» statusCode «:» 200 «}}}

PUT vs POST: в чем разница?

• Домой

• Тестирование

  • • Назад
    • Гибкое тестирование
    • BugZilla
    • Cucumber
    • Тестирование базы данных
    • Тестирование ETL
    • Jmeter

      0

      JIRA 900un

      Ручное тестирование

      Мобильное тестирование

      Mantis

      Почтальон

      QTP

    • Назад
    • Центр качества (ALM)
    • RPA
    • SAP Testing
    • Selenium
    • SoapUI
    • Test Management
    • Test Management

  • SAP

    • • Назад
      • ABAP
      • APO
      • Начало er
      • Basis
      • BODS
      • BI
      • BPC
      • CO
      • Назад
      • CRM
      • Crystal Reports
      • FICO
      • HANA
      • HR
      • MM
      • QM
      • QM Назад
      • PI / PO
      • PP
      • SD
      • SAPUI5
      • Security
      • Solution Manager
      • Successfactors
      • SAP Tutorials

  • Web

    • 09 Apular
      09 Назад
      • ASP.Net
      • C
      • C #
      • C ++
      • CodeIgniter
      • DBMS
      • JavaScript
      • Назад
      • Java
      • JSP
      • Kotlin
      • Linux
      • MariaDB
      • MS Access
      • MS Access js
      • Perl
      • Назад
      • PHP
      • PL / SQL
      • PostgreSQL
      • Python
      • ReactJS
      • Ruby & Rails
      • Scala
      • SQL
      • Назад SQLite
      • 30808
      • UML
      • VB.Net
      • VBScript
      • Веб-службы
      • WPF

    • Обязательно учите!

      • • Назад
        • Бухгалтерский учет
        • Алгоритмы
        • Android
        • Блокчейн
        • Бизнес-аналитик
        • Создание веб-сайта
        • Облачные вычисления
        • COBOL
        • Проектирование компилятора
        • Назад
        Встроенные системы

      Когда использовать HTTP PUT и HTTP POST

      Протокол HTTP определяет два метода обновления ресурса — PUT и ПОСТ .И PUT , и POST используются для изменения ресурса и этого семантического сходство может сбить с толку разработчиков API. Эта путаница привела к тому, что большинство разработчиков используйте POST для любого действия, которое может изменить состояние ресурса, игнорируя ПОСТАВИТЬ целиком.

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

      ПУТ

      Давайте сразу перейдем к HTTP / 1.1 RFC для определения PUT.

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

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

        PUT / пользователь / 1234567890 HTTP / 1.1
      Хост: http://sookocheff.com
      
      {
      "name": "Кевин Сукочев",
      "сайт": "http://kevinsookocheff.com"
      }
        

      Сервер может ответить кодом состояния 201 Создано и новым ресурсом расположение.

        HTTP / 1.1 201 Создано
      Расположение: / user / 1234567890
        

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

        PUT / пользователь / 1234567890 HTTP / 1.1
      Хост: http://sookocheff.com
      
      {
      "name": "Кевин Сукочев",
      "сайт": "http://sookocheff.com"
      }
        

      Обычно метод HTTP PUT заменяет ресурс в текущем URL-адресе ресурс, содержащийся в запросе. PUT используется как для создания, так и для обновления состояние ресурса на сервере.

      ПОСТ

      Давайте вернемся к HTTP / 1.1 RFC для определения POST.

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

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

        POST / пользовательский HTTP / 1.1
      Хост: http://sookocheff.com
      
      {
          "name": "Брайан Ларсон",
          "сайт": "http://www.bryanlarson.ca"
      }
        

      Сервер может ответить кодом состояния 201 Создано и новым ресурсом расположение.

        HTTP / 1.1 201 Создано
      Расположение: / user / 636363
        

      Последующие обновления для этого пользователя будут производиться посредством запроса PUT к конкретный URL для пользователя — / user / 636363 .

      Книга RESTful Web APIs классифицируйте это поведение POST-to-append , и это обычно рекомендуемый способ обрабатывать запрос POST в контексте определенного ресурса.

      Собираем вместе

      HTTP / 1.1 RFC предлагает некоторые рекомендации по различию между POST и ПОЛОЖИТЬ.

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

      Следуя существующей семантике методов HTTP PUT и POST, мы можем начать использовать преимущества REST для написания масштабируемых и надежные API. Ваш API не только готов к масштабированию и прост в обслуживании, но и легко понять и использовать. Последовательно следуя этой существующей семантике вы можете избежать добавления в API особых случаев и ошибок, которые сбивают с толку клиентские разработчики.

      См. Также

      HTTP / 1.1: Определения методов

      HTTP / 1.1: Определения методов
      часть протокола передачи гипертекста — HTTP / 1.1
      RFC 2616 Fielding, et al.

      9 Определения методов

      Набор общих методов для HTTP / 1.1 определен ниже. Хотя этот набор может быть расширен, дополнительные методы не могут быть использовать ту же семантику для отдельно расширенных клиентов и серверов.

      Поле заголовка запроса хоста (раздел 14.23) ДОЛЖНО сопровождать все HTTP / 1.1 просьба.

      9.1 Безопасные и идемпотентные методы

      9.1.1 Безопасные методы

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

      В частности, было установлено, что GET и Методы HEAD НЕ ДОЛЖНЫ иметь значение для выполнения действия кроме поиска.Эти методы следует считать «безопасными». Это позволяет пользовательским агентам представлять другие методы, такие как POST, PUT. и DELETE особым образом, чтобы пользователь знал о тот факт, что запрашивается возможно небезопасное действие.

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

      9.1.2 Идемпотентные методы

      Методы также могут обладать свойством «идемпотентности» в этом (помимо из-за ошибки или истечения срока действия) побочные эффекты N> 0 идентичны запросы такие же, как и для одиночного запроса. Методы GET, HEAD, PUT и DELETE совместно используют это свойство. Также методы OPTIONS и TRACE НЕ ДОЛЖЕН иметь побочных эффектов, и поэтому они по своей природе идемпотентны.

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

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

      9.2 ОПЦИИ

      Метод OPTIONS представляет собой запрос информации о варианты связи, доступные в цепочке запросов / ответов идентифицированный Request-URI. Этот метод позволяет клиенту определять варианты и / или требования, связанные с ресурсом, или возможности сервера, не подразумевая действия ресурса или инициируя поиск ресурса.

      Ответы на этот метод не кэшируются.

      Если запрос OPTIONS включает тело объекта (как указано наличие Content-Length или Transfer-Encoding), затем тип носителя ДОЛЖЕН быть обозначен полем Content-Type. Хотя это спецификация не определяет использование такого тела, будущее расширения HTTP могут использовать тело OPTIONS, чтобы сделать более подробными запросы на сервере. Сервер, который не поддерживает такой extension МОЖЕТ отбросить тело запроса.

      Если Request-URI — звездочка («*»), запрос OPTIONS предназначен для применения к серверу в целом, а не к конкретному ресурс.Поскольку параметры связи сервера обычно зависят от ресурс, запрос «*» полезен только как «пинг» или «без операции» тип метода; он ничего не делает, кроме того, что позволяет клиенту протестировать возможности сервера. Например, это можно использовать для проверки прокси на соответствие HTTP / 1.1 (или его отсутствие).

      Если Request-URI не является звездочкой, применяется запрос OPTIONS. только к тем параметрам, которые доступны при общении с этим ресурс.

      Ответ 200 ДОЛЖЕН включать любые поля заголовка, которые указывают дополнительные функции, реализованные сервером и применимые к нему ресурс (например, Allow), возможно, включая расширения, не определенные эта спецификация. В текст ответа, если таковой имеется, СЛЕДУЕТ также включать информация о вариантах связи. Формат такого

      тело не определено в этой спецификации, но может быть определено будущие расширения HTTP.Согласование содержимого МОЖЕТ использоваться для выбора соответствующий формат ответа. Если тело ответа не включено, ответ ДОЛЖЕН включать поле Content-Length со значением поля «0».

      Поле заголовка запроса Max-Forwards МОЖЕТ использоваться для нацеливания на конкретный прокси в цепочке запросов. Когда прокси получает OPTIONS запрос на absoluteURI, для которого разрешена пересылка запроса, прокси-сервер ДОЛЖЕН проверять поле Max-Forwards.Если Max-Forwards значение поля равно нулю («0»), прокси-сервер НЕ ДОЛЖЕН пересылать сообщение; вместо этого прокси-сервер ДОЛЖЕН отвечать своими собственными параметрами связи. Если значение поля Max-Forwards является целым числом больше нуля, прокси-сервер ДОЛЖЕН уменьшить значение поля при пересылке запроса. Если в запросе нет поля Max-Forwards, то перенаправленное запрос НЕ ДОЛЖЕН включать поле Max-Forwards.

      9,3 ПОЛУЧИТЬ

      Метод GET означает получение любой информации (в виде entity) идентифицируется Request-URI.Если Request-URI ссылается на для процесса производства данных именно произведенные данные должны быть возвращается как объект в ответе, а не как исходный текст процесса, если только этот текст не является результатом процесса.

      Семантика метода GET изменяется на «условный GET», если сообщение запроса включает If-Modified-Since, If-Unmodified-Since, Поле заголовка If-Match, If-None-Match или If-Range. Условный GET метод требует, чтобы объект был передан только под обстоятельства, описанные условным полем (ями) заголовка.В условный метод GET предназначен для сокращения ненужных сетевых использование, позволяя обновлять кэшированные объекты без необходимости множественные запросы или передача данных, уже имеющихся у клиента.

      Семантика метода GET изменяется на «частичный GET», если сообщение запроса включает поле заголовка диапазона. Частичные запросы GET что только часть предприятия будет передана, как описано в разделе 14.35. Частичный метод GET предназначен для сокращения ненужных использование сети, позволяя частично извлеченным объектам быть завершено без передачи данных, уже имеющихся у клиента.

      Ответ на запрос GET кэшируется тогда и только тогда, когда он соответствует требования к HTTP-кешированию, описанные в разделе 13.

      См. Раздел 15.1.3 для ознакомления с соображениями безопасности при использовании для форм.

      9,4 ГОЛОВКА

      Метод HEAD идентичен GET, за исключением того, что сервер НЕ ДОЛЖЕН вернуть тело сообщения в ответ. Метаинформация содержала в заголовках HTTP в ответ на запрос HEAD ДОЛЖНЫ быть идентичными к информации, отправленной в ответ на запрос GET.Этот метод может использоваться для получения метаинформации о сущности, подразумеваемой запрос без передачи самого тела объекта. Этот метод часто используется для проверки гипертекстовых ссылок на валидность, доступность, и недавняя модификация.

      Ответ на запрос HEAD МОЖЕТ быть кэшируемым в том смысле, что информация, содержащаяся в ответе, МОЖЕТ использоваться для обновления ранее кэшированный объект из этого ресурса. Если новые значения поля указывают, что кэшированный объект отличается от текущего объекта (как будет обозначено изменением Content-Length, Content-MD5, ETag или Last-Modified), то кеш ДОЛЖЕН обрабатывать запись кэша как несвежий.

      9,5 ПОСТ

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

       - Аннотация существующих ресурсов;
       

       - Отправка сообщения на доску объявлений, группу новостей, список рассылки,
              или аналогичная группа статей;
       

       - Предоставление блока данных, например, в результате отправки
              форма для процесса обработки данных;
       

       - Расширение базы данных с помощью операции добавления.

      Фактическая функция, выполняемая методом POST, определяется server и обычно зависит от Request-URI. Размещенная сущность подчиняется этому URI так же, как файл подчиняется к каталогу, содержащему его, новостная статья подчиняется группа новостей, в которой она размещена, или запись подчиняется база данных.

      Действие, выполняемое методом POST, может не привести к ресурс, который можно идентифицировать по URI.В этом случае либо 200 (ОК) или 204 (Нет содержимого) — соответствующий статус ответа, в зависимости от того, содержит ли ответ объект, который описывает результат.

      Если ресурс был создан на исходном сервере, ответ ДОЛЖЕН быть 201 (Создано) и содержать объект, который описывает статус запроса и относится к новому ресурсу, а Location заголовок (см. раздел 14.30).

      Ответы на этот метод не кэшируются, если только ответ включает соответствующие поля заголовка Cache-Control или Expires.Тем не мение, ответ 303 (см. прочее) можно использовать для направления пользовательского агента на получить кэшируемый ресурс.

      Запросы POST ДОЛЖНЫ подчиняться изложенным требованиям передачи сообщений. в разделе 8.2.

      См. Раздел 15.1.3 по соображениям безопасности.

      9,6 ПУТ

      Метод PUT запрашивает, чтобы закрытый объект хранился в предоставленный Request-URI. Если Request-URI ссылается на уже существующий ресурс, закрытый объект СЛЕДУЕТ рассматривать как модифицированная версия того, что находится на исходном сервере.Если Request-URI не указывает на существующий ресурс, и этот URI может быть определен как новый ресурс запрашивающим пользователем агент, исходный сервер может создать ресурс с этим URI. Если создается новый ресурс, исходный сервер ДОЛЖЕН проинформировать пользовательский агент через ответ 201 (Создано). Если существующий ресурс изменен, ДОЛЖНЫ быть отправлены коды ответа 200 (ОК) или 204 (Нет содержимого) чтобы указать на успешное выполнение запроса.Если ресурс не может быть создан или изменен с помощью Request-URI, подходящего СЛЕДУЕТ дать ответ об ошибке, который отражает характер проблема. Получатель объекта НЕ ДОЛЖЕН игнорировать любой Content- * (например, Content-Range) заголовки, которые он не понимает или не реализует и ДОЛЖЕН возвращать ответ 501 (Не реализовано) в таких случаях.

      Если запрос проходит через кеш и Request-URI идентифицирует один или несколько кэшированных в настоящее время объектов, эти записи ДОЛЖНЫ быть считается устаревшим.Ответы на этот метод не кэшируются.

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

      он ДОЛЖЕН отправить ответ 301 (перемещен навсегда); пользовательский агент МОЖЕТ затем принять собственное решение относительно того, перенаправлять или нет запрос.

      Один ресурс МОЖЕТ быть идентифицирован множеством разных URI. За например, у статьи может быть URI для идентификации «текущего версия «, который отличается от URI, определяющего каждый конкретный версия.В этом случае запрос PUT для общего URI может привести к несколько других URI, определяемых исходным сервером.

      HTTP / 1.1 не определяет, как метод PUT влияет на состояние исходный сервер.

      Запросы PUT ДОЛЖНЫ подчиняться изложенным требованиям к передаче сообщений. в разделе 8.2.

      Если иное не указано для конкретного заголовка объекта, заголовки сущностей в запросе PUT ДОЛЖНЫ применяться к ресурсу созданный или измененный PUT.

      9,7 УДАЛИТЬ

      Метод DELETE запрашивает у исходного сервера удаление ресурса. идентифицированный Request-URI. Этот метод МОЖЕТ быть переопределен человеком. вмешательство (или другие средства) на исходный сервер. Клиент не может гарантировать, что операция была проведена, даже если код состояния, возвращенный исходным сервером, указывает, что действие был успешно завершен. Однако серверу НЕ СЛЕДУЕТ указывает на успех, если в момент получения ответа намеревается удалить ресурс или переместить его в недоступный расположение.

      Успешный ответ ДОЛЖЕН быть 200 (OK), если ответ включает сущность, описывающая статус, 202 (Принято), если действие не еще не было выполнено, или 204 (Нет содержимого), если действие было выполнено но ответ не включает сущность.

      Если запрос проходит через кеш и Request-URI идентифицирует один или несколько кэшированных в настоящее время объектов, эти записи ДОЛЖНЫ быть считается устаревшим. Ответы на этот метод не кэшируются.

      9,8 СЛЕД

      Метод TRACE используется для вызова удаленного цикла на уровне приложения. обратная сторона сообщения запроса. Конечный получатель запроса ДОЛЖЕН отражать полученное сообщение обратно клиенту как entity-body ответа 200 (ОК). Конечным получателем является либо

      исходный сервер или первый прокси или шлюз, который получит Max-Forwards значение нуля (0) в запросе (см. раздел 14.31). Запрос TRACE НЕ ДОЛЖЕН включать сущность.

      TRACE позволяет клиенту видеть, что получает другой конец цепочки запросов и использовать эти данные для тестирования или диагностики Информация. Значение поля заголовка Via (раздел 14.45) равно особый интерес, поскольку он действует как след цепочки запросов. Использование поля заголовка Max-Forwards позволяет клиенту ограничивать длина цепочки запросов, что полезно для тестирования цепочки прокси пересылают сообщения в бесконечном цикле.

      Если запрос действителен, ответ ДОЛЖЕН содержать все сообщение запроса в теле объекта с типом содержимого «сообщение / http». Ответы на этот метод НЕ ДОЛЖНЫ кэшироваться.

      9.9 ПОДКЛЮЧИТЬ

      В этой спецификации зарезервировано имя метода CONNECT для использования с прокси, который может динамически переключаться на туннель (например, SSL туннелирование [44]).

      PUT и POST — сравнение методов HTTP

      Обновлено 4 октября 2018 г.

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

        GET https://website.com/path/to/image.jpg
        

      Однако, помимо GET , существуют и другие типы HTTP-методов, в том числе:

      • HEAD
      • POST POST POST
      • PUT
      • DELETE
      • DELETE
      • TRACE

      Два из этих методов иногда путают в отношении того, когда следует использовать каждый из них.Здесь речь идет о двух методах: PUT и POST . В этой статье мы поговорим конкретно о том, в чем разница между PUT и POST , а также о том, как правильно использовать каждый метод.

      Что делает метод PUT ?

      Метод PUT полностью заменяет все, что в настоящее время существует по целевому URL, чем-то другим. С помощью этого метода вы можете создать новый ресурс или перезаписать существующий с учетом , вам известен точный Request-URI .Пример метода PUT , используемого для создания нового ресурса, будет выглядеть следующим образом:

        PUT / forum /  HTTP / 2.0
      Хост: yourwebsite.com
        

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

        PUT / forum /  HTTP / 2.0
      Хост: yourwebsite.com
        

      Короче говоря, метод PUT используется для создания или перезаписи ресурса по конкретному URL-адресу, известному клиенту .

      Что делает метод POST ?

      Метод HTTP POST используется для отправки пользовательских данных на веб-сервер. Например, метод POST используется, когда пользователь комментирует форум или загружает изображение профиля. Также следует использовать метод POST , если вы не знаете конкретный URL-адрес , где должен находиться ваш вновь созданный ресурс. Другими словами, если создается новая ветка форума и путь к ней не указан, вы можете использовать что-то вроде:

        POST / forum HTTP / 2.0
      Хост: yourwebsite.com
        

      Используя этот метод, путь URL-адреса будет возвращен с исходного сервера, и вы получите ответ, подобный:

        HTTP / 2.0 201 Created
      Расположение: / форумы / 
        

      Короче говоря, метод POST следует использовать для создания подчиненного (или дочернего) ресурса, идентифицированного Request-URI. В приведенном выше примере Request-URI будет / forum , а подчиненным или дочерним будет , как определено источником.

      Когда использовать PUT и POST

      Итак, теперь, когда вы знаете больше о разнице между PUT и POST , вы должны лучше понимать, какой из них использовать в определенных обстоятельствах. Однако в этом разделе мы постараемся уточнить, когда использовать каждый метод.

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

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

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

      RFC 2616, объясняет разницу между PUT и POST следующим образом.

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

      Если вы знаете URL-адрес объекта, который хотите создать или перезаписать, следует использовать метод PUT . В качестве альтернативы, если вам известен только URL-адрес категории или подраздела объекта, в котором вы хотите что-то создать, используйте метод POST .

      Сводка

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

      HTTP-методы - Учебник по REST API

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

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

       Содержание
      
      HTTP GET
      HTTP POST
      HTTP PUT
      HTTP УДАЛИТЬ
      HTTP-ПАТЧ
      Резюме
      Глоссарий 

      HTTP GET

      Используйте запросы GET для получения только представления ресурса / информации - и не изменять его каким-либо образом. Поскольку запросы GET не изменяют состояние ресурса, это безопасных методов . Кроме того, API-интерфейсы GET должны быть idempotent , что означает, что выполнение нескольких идентичных запросов должно приводить к одному и тому же результату каждый раз, пока другой API (POST или PUT) не изменит состояние ресурса на сервере.

      Если Request-URI относится к процессу создания данных, то в качестве объекта в ответе должны быть возвращены произведенные данные, а не исходный текст процесса, если только этот текст не является выходом процесса. .

      Для любого заданного HTTP GET API, если ресурс найден на сервере, он должен вернуть код ответа HTTP 200 (OK) - вместе с телом ответа, которое обычно является содержимым XML или JSON (из-за их платформенно-независимый характер).

      Если ресурс НЕ найден на сервере, он должен вернуть код ответа HTTP 404 (НЕ НАЙДЕН) . Точно так же, если определено, что сам запрос GET сформирован неправильно, сервер вернет код ответа HTTP 400 (ПЛОХОЙ ЗАПРОС) .

      Пример URI запроса

      • HTTP GET http://www.appdomain.com/users
      • HTTP GET http://www.appdomain.com/users?size=20&page=5
      • HTTP GET http: // www.appdomain.com/users/123
      • HTTP GET http: // www.appdomain.com/users/123/address

      HTTP POST

      Используйте API-интерфейсы POST для создания новых подчиненных ресурсов , например, файл подчиняется каталогу, содержащему его, или строка подчиняется таблице базы данных. Если говорить строго в терминах REST, методы POST используются для создания нового ресурса в коллекции ресурсов.

      В идеале, если ресурс был создан на исходном сервере, ответ ДОЛЖЕН иметь код ответа HTTP 201 (Создано) и содержать объект, который описывает статус запроса и ссылается на новый ресурс, и заголовок Location. .

      Часто действие, выполняемое методом POST, может не привести к ресурсу, который может быть идентифицирован с помощью URI. В этом случае либо код ответа HTTP 200 (ОК) , либо 204 (Нет содержимого) является подходящим статусом ответа.

      Ответы на этот метод: не кэшируются , если ответ не включает соответствующие поля заголовка Cache-Control или Expires.

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

      Пример URI запроса

      • HTTP POST http://www.appdomain.com/users
      • HTTP POST http://www.appdomain.com/users/123/accounts

      HTTP PUT

      Использовать API PUT в первую очередь для обновления существующего ресурса (если ресурс не существует, тогда API может решить создать новый ресурс или нет). Если с помощью PUT API был создан новый ресурс, исходный сервер ДОЛЖЕН проинформировать пользовательский агент с помощью ответа HTTP с кодом 201 (Создано) ответ , а если существующий ресурс изменен, либо 200 (OK), или СЛЕДУЕТ отправлять коды ответа 204 (No Content ), чтобы указать на успешное выполнение запроса.

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

      Разницу между API POST и PUT можно увидеть в URI запроса. Запросы POST выполняются для коллекций ресурсов, тогда как запросы PUT выполняются для одного ресурса.

      Пример URI запроса

      • HTTP PUT http://www.appdomain.com/users/123
      • HTTP PUT http: // www.appdomain.com/users/123/accounts/456

      HTTP DELETE

      В соответствии с названием используются API-интерфейсы DELETE для удаления ресурсов (идентифицируемых Request-URI).

      Успешный ответ на запросы DELETE ДОЛЖЕН иметь код ответа HTTP 200 (ОК) , если ответ включает объект, описывающий статус, 202 (Принято) , если действие было поставлено в очередь, или 204 (Нет содержимого) если действие было выполнено, но ответ не содержит сущности.