HATEOAS: краткое описание

Я пытаюсь получить четкое и краткое представление о HATEOAS, и я отнюдь не эксперт WRT REST (я думаю, что получаю это, хотя благодаря http://tomayko.com/writings/rest-to-my-wife)

Может ли кто-нибудь предложить разукрасить блог/статью WRT HATEOAS?

ОТВЕТЫ

Ответ 1

Ограничение Hypermedia (ранее известное как HATEOAS) - это ограничение, которое используется для указания направления пользовательскому агенту.

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

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

Пользовательский агент, соответствующий ограничению Hypermedia, действует как конечный автомат, где переходы состояния вызваны следующими ссылками, доступными в текущем представлении. Возвращаемое представление становится новым.

Преимущества этого подхода могут быть очень легким пользовательским агентом. Для управления состоянием требуется очень мало кода, так как его действия должны основываться исключительно на полученном ответе и на ссылке, которая получила этот ответ. Код пользовательского агента становится декларативным и реактивным, а не императивными последовательностями GET, тогда сделайте это, а затем сделайте это, у вас просто есть механика для следующих ссылок и много случаев КОГДА вы получаете это ТОГДА.

Для примера того, как это работает, вам нужно смотреть не дальше, чем на ваш веб-браузер и веб-сайт, который не использует Javascript. В браузере представлены параметры, основанные на ссылках в HTML. Когда вы переходите по этой ссылке, браузер заменяет свое текущее состояние новым состоянием, полученным при выполнении этой ссылки. Кнопка "Назад" работает (или, по крайней мере, должна), потому что вы извлекаете состояние из ссылки в своей истории. Браузеру все равно, как вы попали на страницу, поскольку состояние должно основываться исключительно на полученном представлении.

Эта модель управления состоянием может быть очень ограничена, так как ваше текущее состояние приложения основано на ответе на один сервер. Однако сложные приложения могут быть созданы с использованием набора пользовательских агентов, работающих вместе. Это часть того, что достигается AJAX, поскольку он позволяет использовать отдельный пользовательский агент для создания отдельных запросов и, следовательно, управлять другим конечным автоматом. К сожалению, в большинстве случаев люди прибегают к RPC-стилю, когда начинают писать javascript-запросы, что, к сожалению, связано с естественной асинхронностью Javascript.

Ответ 2

HATEOAS в нескольких словах: В выводимых вами данных обратитесь к другим ресурсам, используя URI, а не идентификаторы.

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

Теперь, для более длинного объяснения.

Принцип HATEOAS гласит, что состояние вашего приложения должно продвигаться через гипертекстовые ссылки. Подумайте о том, как вы просматриваете интернет. Сначала вы должны ввести адрес в адресной строке. С этого момента ваша навигация продвигается в значительной степени только благодаря кликам по ссылкам: вы нажимаете на ссылку, и вы попадаете на другую страницу. Еще один щелчок и здесь появляется другая страница. Как браузер мог перенести вас с первой страницы на вторую на третью? Он использовал URL-адреса, закодированные в элементах <a>.

Аналогично, если ваши приложения REST генерируют этот результат

<accomodation>
  <hotel info="http://example/hotel/0928374" price="200"/>
  <guest-house info="http://example/guest-h/7082" price="87"/>
</accomodation>

тогда получающему приложению не придется обращаться к каким-либо внешним источникам знаний, чтобы знать, что первый отель доступен в http://example/hotel/0928374, а второй - в http://example/guest-h/7082.

С другой стороны, если ваше приложение генерирует ответы с идентификаторами типа

<accomodation>
  <hotel id="0928374" price="200"/>
  <guest-house id="7082" price="87"/>
</accomodation>

получающее приложение должно заранее знать, как идентификаторы должны быть составлены с префиксами, чтобы получить URI, по которому доступна информация для каждого размещения (например, "добавить http://example/" к каждому запросу, а затем добавить hotel для отели и guest-h для гостевых домов "). Вы можете видеть, что этот механизм похож на то, что происходит во многих приложениях БД, но отличается от того, как работают браузеры.

Важно следовать принципу HATEOAS, потому что он позволяет приложениям расти без существенных изменений в принимающих приложениях. Предположим, вы хотите изменить URI с http://example.com/hotel/0928374 на https://reviews.example.com/accommodation/0928374. Если вы следуете HATEOAS, это будет простое изменение: измените возвращаемые значения и что это будет: получение приложений будет продолжать работать без каких-либо изменений. Если вместо этого у вас есть отдельная документация для создания URI, вам придется связаться со всеми разработчиками приложений и попросить их заметить, что документация обновлена, и они должны изменить свой код, чтобы отразить изменения.

Отказ от ответственности: это быстрый ответ, который просто царапает поверхность проблемы. Но если вы получите это, вы получите 80% принципа HATEOAS.

Ответ 3

Это отличное видео, объясняющее ограничение Hypermedia REST.

https://vimeo.com/20781278

Ответ 4

Одной из проблем с REST и HATEOAS является сложность и отсутствие видимости и контроля над определением интерфейса. При более традиционном взаимодействии с RPC обычно существовал артефакт, такой как IDL или WSDL, который определял API и мог контролироваться и управляться проектом.

С HATEOAS API динамически отпадает, и его можно описать как набор поведений (изменения состояния). Поведение описано в коде. Описание API (WADL) генерируется из кода, а не кода, генерируемого из описания интерфейса.

Ответ 5

Из моего личного опыта работы с двигателем HATEOAS самая большая разница - это философия самого дизайна.

Если мы собираемся создать веб-приложение, для него есть два подхода. Один из них - стиль RPC, а другой - стиль REST.

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

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

С точки зрения компьютерной науки, один является процедурным стилем и является алгоритмическим. где, поскольку стиль REST является интерактивной парадигмой. Любая система, которая принимает интерактивную парадигму как язык, будет поставлять систему HATEOAS.

Ответ 6

Эта статья помогла мне понять это полностью. http://restcookbook.com/Basics/hateoas/

Это просто и элегантно.

HATEOAS означает Hypertext как механизм состояния приложения. Это означает, что гипертекст должен использоваться для поиска вашего пути через API. Пример:

GET /account/12345 HTTP/1.1

HTTP/1.1 200 OK
<?xml version="1.0"?>
<account>
    <account_number>12345</account_number>
    <balance currency="usd">100.00</balance>
    <link rel="deposit" href="/account/12345/deposit" />
    <link rel="withdraw" href="/account/12345/withdraw" />
    <link rel="transfer" href="/account/12345/transfer" />
    <link rel="close" href="/account/12345/close" />
</account>

Кроме того, что у нас есть 100 долларов США (US) на нашем счете, мы можем видеть 4 варианта: внести больше денег, снять деньги, перевести деньги на другой аккаунт или закрыть нашу учетную запись. "Link" -tags позволяют нам узнать URL-адреса, необходимые для указанных действий. Теперь предположим, что у нас не было 100 долларов в банке, но мы на самом деле в красном:

GET /account/12345 HTTP/1.1

HTTP/1.1 200 OK
<?xml version="1.0"?>
<account>
    <account_number>12345</account_number>
    <balance currency="usd">-25.00</balance>
    <link rel="deposit" href="/account/12345/deposit" />
</account>

Теперь мы красные 25 долларов. Вы видите, что прямо сейчас мы потеряли многие наши варианты, и только внесение денег действительно? Пока мы краснеем, мы не можем закрыть нашу учетную запись, не передавать и не выводить деньги со счета. Гипертекст на самом деле говорит нам, что разрешено, а что нет: HATEOAS