Скрытый язык компьютеров и необходимость говорить

:::

Он работает поверх реальных транспортных протоколов, таких как TCP/IP (ориентированный на соединение) или UDP или QUIC (без соединения) в случае HTTP2.

HTTP-глаголы (методы)

Чтобы перетасовать документ, HTTP определяет очень мало команд, ограничивающихся GET, PUT, DELETE и POST

• GET — получение документа
• PUT — размещение документа
• DELETE — удаление документа

И давайте пока не будем говорить о POST, вернемся к этому позже.

Диалог

На изображении выше изображен простой диалог между пользователем и некоторым веб-приложением. Каждое сообщение в этом диалоге представляет собой своего рода документ, передаваемый между сторонами. Давайте пока не будем беспокоиться о том, что перетасовано. Он отслеживает рабочий процесс веб-приложения.

Типы медиа

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

* текстовый/обычный * текст/html * изображение/jpg * приложение/xml * application/vnd.example+xml

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

Давайте прочитаем последний тип носителя

• приложение

Мультимедиа предназначены для использования приложением, а не людьми * внд

Это пользовательский тип носителя, определенный поставщиком. * пример

Это имя типа носителя, указанное поставщиком * +xml

Этот тип носителя основан на уже известном типе носителя xml

Гипер-Типы медиа

Теперь мы рассмотрели типы мультимедиа. Что означает Гипер? Пользователь использует какое-то приложение, которое обращается к серверу от имени пользователя. Приложения, используемые пользователями, называются пользовательскими агентами. Веб-браузер является примером пользовательского агента. Эти пользовательские агенты понимают и понимают медиа, которые передаются на сервер и с него.

Подталкивание

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

Рассмотрим следующее взаимодействие, которое представляет собой один запрос-ответ.

Запрос

POST /orders

Host: example.org

Content-type: application/vnd.example+xml

Accept: application/vnd.example+xml

<order xmlns=“http://schemas.example.org/”>

<item qty=“2”>ITEM-1</item>

</order>

Ответить

HTTP/1.1 201 Order created

Location: http://example.org/orders/1234

Content-Type:  application/vnd.example+xml

<order xmlns=“http://schemas.example.org/”>

<item qty=“2”>ITEM-1</item>

<next xmlns=“http://schemas.example.org/state-machine”

rel=“payment”

uri=“http://example.org/orders/1234/payment”

/>

<next xmlns=“http://schemas.example.org/state-machine”

rel=“self”

uri=“http://example.org/orders/1234”

/>

</order>

Давайте посмотрим, какой пользовательский агент отправляет запрос

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

Один из HTTP-глаголов в приведенном выше запросе — POST * URI запроса

URI ресурса. В приведенном выше запросе это /orders * Заголовки запросов

Accept позволяет серверу узнать, какой тип мультимедиа интересует пользовательского агента

Content-Type сообщает серверу, в каком формате отправляются данные в запросе * Тело запроса

И, наконец, данные, отправляемые на сервер.

Давайте разберем ответ, полученный от сервера

• Координация действий пользователя и агента
<ли>

Здесь говорится о последствиях запроса

HTTP/1.1 ==201==* Заказ создан***

201 — это код состояния, сообщающий пользовательскому агенту, что запрос успешно выполнен и, как следствие, создается ресурс. Ресурс может показаться слишком техническим, но на самом деле это просто означает, что на сервере создается новый объект. * Местоположение: http://example.org/orders/1234

Местоположение – это заголовок ответа. Он сообщает пользовательскому агенту, что если он заинтересован, он может перейти по ссылке в заголовке и перенаправить пользовательского агента, в данном случае, на вновь созданный ресурс. * Тип контента: application/vnd.example+xml

Он просто сообщает пользовательскому агенту, что отправляемые ему данные используют тип носителя application/vnd.example+xml. * Носители или сами данные. * Остальные байты, отправленные сервером, представляют собой просто фактические данные.

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

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

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

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

Предположим, пользователь хочет отменить заказ

Запрос

DELETE /orders/1234
Host: example.org
Accept: application/vnd.example+xml

Ответить

HTTP/1.1 200 Okay

Content-Type:  application/vnd.example+xml

<order xmlns=“http://schemas.example.org/”>

<item qty=“2”>ITEM-1</item>

<status>Cancelled</status>

</order>

Или пользователь хочет продолжить оплату

Запрос

POST /orders/1234/payment

Host: example.org

Content-Type:  application/vnd.example+xml

Accept: application/vnd.example+xml

<payment orderId=“1234” xmlns=“http://schemas.example.org/”>

…

</order>

Ответить

HTTP/1.1 201 Receipt generated

Location: http://example.org/orders/1234/receipt

Content-Type:  application/vnd.example+xml

<order xmlns=“http://schemas.example.org/”>

<item qty=“2”>ITEM-1</item>

<next xmlns=“http://schemas.example.org/state-machine”

rel=“self”

uri=“http://example.org/orders/1234”

/>

<status>Not Ready</status>

</order>

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

В случае, если пользовательский агент следил за платежами и они были успешно обработаны, будет сгенерирована квитанция о побочном эффекте. Данные координации сообщают об этом 201 и дают uri для получения в качестве заголовка Location. Теперь клиент может опросить собственный uri, чтобы узнать, готов ли заказ.

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

Любопытный случай POST

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

Теперь о POST, который был введен немного по-другому. Я рассматриваю это после других глаголов. Создание в основном связано с POST, хотя на самом деле эту работу может выполнить GET, за которым следует PUT.

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

1. Получить последний заказ
2. Создать новый заказ локально и вернуть его.

Тогда почему POST?

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

.

Допустим, новый идентификатор заказа является функцией количества заказов в коллекции + 1. Поскольку это многопользовательское приложение, одновременно может быть несколько пользователей, желающих создать новый заказ. Все эти пользователи запрашивают GET идентификатор последнего заказа, и все в конечном итоге получают одинаковый результат. Когда эти пользователи PUT создают новый заказ, побеждает тот, кто сделает это последним. Пользователи узнают о неудаче или успехе, только GETпроверив заказ по идентификатору заказа и сверив его с локально созданным заказом. Неудачливые пользователи просто должны повторять ту же последовательность действий, пока не добьются успеха. Скорее, если пользователи просто сообщат серверу о своем намерении создать новый заказ, и всемогущий сервер, имеющий целостное состояние приложения, будет лучше знать, как обрабатывать запросы. GET / PUT / DELETE или любая их последовательность будет недостаточной для выражения такого намерения, поэтому POST. Неудивительно, что это звучит и кажется чуждым.

Согласованность кэша

Однако кэши создают проблему согласованности. Допустим, клиенту было приказано кэшировать ответ на несколько секунд, а тем временем заказ готов. Клиент на основании кэшированного ответа принял решение отменить заказ. В этом случае состояние клиента и сервера разошлось. Чтобы сделать отмену безопасной, клиент может добавить условие в виде заголовка If-Match. Сервер, в случае, если условие не соответствует, просто отказывается обрабатывать запрос, сообщая клиенту, что предварительное условие для выполнения запроса не выполнено. В маловероятном случае клиент не отправил заголовки If-Match, сервер все равно может сообщить об этом как о конфликте 409. Или 406 неприемлемо.

---

Запрос

DELETE /orders/1234

Host: example.org

If-Match: status=Not Ready

Accept: application/vnd.example+xml

Ответить

HTTP/1.1 412 Precondition failed.

Content-Type:  application/vnd.example+xml

<order xmlns=“http://schemas.example.org/”>

<item qty=“2”>ITEM-1</item>

<next xmlns=“http://schemas.example.org/state-machine”

rel=“self”

uri=“http://example.org/orders/1234”

/>

<status>Ready</status>

</order>

---

Отменил заказ, но ==Почему?==

Как бизнес-пользователь, разве вы не хотели бы знать, почему заказ был отменен? Эти причины выходят за рамки проектирования API и больше углубляются в бизнес-задачи. Если API реализовал DELETE для отмены заказа, типичное взаимодействие может выглядеть следующим образом.

Запрос

DELETE /orders/1234

Host: example.org

Accept: application/vnd.example+xml

Ответить

HTTP/1.1 200 Okay

Content-Type:  application/vnd.example+xml

<order xmlns=“http://schemas.example.org/”>

<item qty=“2”>ITEM-1</item>

<status>Cancelled</status>

</order>

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

Давайте попробуем использовать POST

Запрос

POST /orders

Host: example.org

Accept: application/vnd.example+xml

OrderId=14

&Operation=Cancel

&Reason=Just to annoy you

Ответить

HTTP/1.1 200 Okay

Content-Type:  application/vnd.example+xml

<order xmlns=“http://schemas.example.org/”>

<item qty=“2”>ITEM-1</item>

<status>Cancelled</status>

</order>

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

Можем ли мы добиться большего?

Как только мы начнем ограничивать себя только четырьмя глаголами, которые предоставляет HTTP, мы определенно сможем добиться большего. Давайте вернемся к той же проблеме с ограничениями проектирования API.

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

Запрос

POST /CancelledOrders

Host: example.org

Accept: application/vnd.example+xml

OrderId=14

&Reason=Just to annoy you

Ответить

HTTP/1.1 200 Okay

Content-Type:  application/vnd.example+xml

<order xmlns=“http://shemas.example.org/”>

<item qty=“2”>ITEM-1</item>

<status>Cancelled</status>

</order>

Хотя кажется, что придумывать имена просто, это очень утомительно. Неудивительно, что ярый сторонник ReST, Марк Бейкер или Тим-Бернерс Ли, предложил не делать этого. добавить какое-либо значение к URI и сделать их непрозрачными.

Непрозрачные URI избавляют нас от необходимости время от времени создавать новые существительные за счет понятного API. Это также затрудняет документирование API, поскольку конечные точки API определяются во время выполнения. Кроме того, безопасность и соответствующие функции могут быть полезны только после установки непрозрачного URI.

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

Представления

Теперь давайте сосредоточимся на ==ReST==. Это не ресурс, который отправляется пользовательскому агенту. Пользовательский агент запрашивает конкретный тип мультимедиа, который он может понять. Давайте рассмотрим следующее HTTP-взаимодействие.

Запрос

GET /orders/1234

Host: example.org

Accept: text/plain

Ответить

Если веб-приложение не понимает запрошенный тип носителя, оно может просто указать эту неспособность как

HTTP/1.1 415 Unsupported Media Type.

Or if it does indeed supports the requested media type

HTTP/1.1 200 Okay

Content-Type: text/plain

Order 1234 is not ready

Если пользовательский агент запрашивает типы мультимедиа, которые поддерживаются веб-приложением, он может отправить данные ресурса, соответствующие запрошенному типу мультимедиа. Здесь это один и тот же ресурс, но отформатированный как разные типы мультимедиа, и все эти варианты одного и того же ресурса называются представлениями. Поскольку данные, которые передаются между пользовательским агентом и сервером, могут представлять собой разные представления, они известны как ==Re==presentational ==S==tate ==T==transfer или просто ReST.

Дополнительная литература

Диссертация Роя Филдинга

---

Оригинал