HATEOAS: краткое описание - PullRequest
46 голосов
/ 08 февраля 2012

Я пытаюсь получить четкое и краткое понимание HATEOAS, и я ни в коем случае не эксперт WRT REST.(Я думаю, что я все понимаю, благодаря этому http://www.looah.com/source/view/2284).

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

Ответы [ 5 ]

59 голосов
/ 08 февраля 2012

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

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

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

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

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

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

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

47 голосов
/ 08 февраля 2012

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 голосов
/ 05 сентября 2016

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

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

HATEOAS означает Гипертекст как двигатель состояния приложения . Это означает, что гипертекст должен использоваться, чтобы найти свой путь через 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 долларов (США) на нашем счете, мы можем видеть 4 варианта: внести больше денег, вывести деньги, перевести деньги на другой счет или закрыть наш счет. Теги "link" позволяют нам узнать 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

3 голосов
/ 09 февраля 2012

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

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

2 голосов
/ 26 февраля 2015

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

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

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

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

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

...