HATEOAS: краткое описание
Я пытаюсь получить четкое и краткое понимание HATEOAS, и я ни в коем случае не эксперт WRT REST. (Я думаю, что я понимаю, хотя, благодаря этому http://www.looah.com/source/view/2284).
Кто-нибудь может предложить такой же вдохновляющий блог / статью WRT HATEOAS?
5 ответов
Ограничение гипермедиа (ранее известное как HATEOAS) - это ограничение, которое используется для предоставления руководства агенту пользователя.
Включая ссылки в возвращаемые представления, сервер может снять с пользователя-агента бремя определения действий, которые могут быть предприняты, на основе текущего состояния приложения и знания того, с кем следует взаимодействовать для достижения этой цели.
Поскольку сервер не знает о текущем состоянии пользовательского агента, кроме того, что он получает в запросе, важно, чтобы пользовательский агент старался избегать использования состояния, отличного от представлений, возвращаемых с сервера. Это гарантирует, что доступные действия, предоставляемые сервером, основаны на наиболее полном понимании состояния агента пользователя, насколько это возможно.
Пользовательский агент, соответствующий ограничению Hypermedia, действует как конечный автомат, где переходы состояний вызваны следующими ссылками, доступными в текущем представлении. Возвращенное представление становится новым состоянием.
Преимуществами такого подхода может быть очень легкий пользовательский агент. Для управления состоянием требуется очень мало кода, поскольку его действия должны основываться исключительно на полученном ответе и ссылке, которая получила этот ответ. Код пользовательского агента становится декларативным и реактивным, а не императивными последовательностями GET, затем делайте это и затем делайте это, у вас просто есть механизм для перехода по ссылкам, и во многих случаях, когда вы получаете это, ТОГДА это делаете.
В качестве примера того, как это работает, вам не нужно смотреть дальше своего веб-браузера и веб-сайта, который не использует Javascript. Браузер предоставляет вам варианты, основанные на ссылках в HTML. Когда вы переходите по этой ссылке, браузер заменяет свое текущее состояние новым состоянием, полученным при переходе по ссылке. Кнопка "Назад" работает (или, по крайней мере, должна), потому что вы извлекаете состояние из ссылки в своей истории. Браузер не должен заботиться о том, как вы попали на страницу, поскольку состояние должно полностью основываться на полученном представлении.
Эта модель "управления состоянием" может быть очень ограниченной, поскольку текущее состояние приложения основано на ответе одного сервера. Однако сложные приложения могут быть созданы с использованием набора пользовательских агентов, работающих вместе. Это часть достижения AJAX в том, что он позволяет использовать отдельный пользовательский агент для выполнения отдельных запросов и, следовательно, фактически управлять другим конечным автоматом. К сожалению, большую часть времени люди возвращаются к стилю RPC, когда начинают делать запросы javascript, что, к сожалению, с учетом естественной асинхронности Javascript.
HATEOAS в двух словах: в выводимых вами данных обращайтесь к другим ресурсам, используя URI, а не ID.
Как и все короткие определения, определение, которое я только что дал, неверно на многих уровнях, но оно должно помочь вам понять, в чем суть 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.
Эта статья помогла мне понять это полностью. 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
Одной из проблем REST & HATEOAS является сложность и отсутствие видимости и контроля определения интерфейса. При более традиционном взаимодействии в стиле RPC обычно возникали такие артефакты, как IDL или WSDL, которые определяли API и могли контролироваться и управляться проектом.
С HATEOAS API-интерфейс может быть обнаружен динамически, и его можно описать как набор поведений (изменение состояния). Поведения описаны в коде. Описание API (WADL) генерируется из кода, а не кода, генерируемого из описания интерфейса.
Из моего личного опыта работы с двигателем HATEOAS самым большим отличием является философия самого дизайна.
Если мы собираемся создать веб-приложение, есть два подхода к нему. Один - это стиль RPC, а другой - стиль REST.
Если состояние должно быть проверено в стиле RPC, нам нужно вызвать процедуру RPC, которая возвращает результат. При таком подходе к проектированию параметры, возвращаемые после первого вызова, должны храниться на клиенте, чтобы при последующих вызовах можно было использовать параметры, которые были возвращены. Это просто делает клиент и сервер тесно связанными, делая общую систему состоящей из состояний.
В то время как в стиле REST нет RPC. Важным является взаимодействие между клиентом и сервером. Для любого перехода состояния клиент должен взаимодействовать с сервером для получения информации. Единственное фиксированное взаимодействие - это домашнее взаимодействие. Все остальные обнаруживаются клиентом, когда он проходит через различные взаимодействия.
С точки зрения информатики, один - это процедурный стиль и он алгоритмический. где стиль REST - это интерактивная парадигма. Любая система, которая использует интерактивную парадигму в качестве языка, будет предоставлять систему HATEOAS.