HATEOAS (гипермедиа как двигатель состояния приложения) является одним из наиболее важных ограничений в REST. Все же некоторые объяснения этого принципа, найденные в сети, немного туманны; Я видел HATEOAS, представленный в нескольких разных соусах, и в этой статье я перечислю эти примеры и составлю простое сравнение, чтобы понять его менее чем за 5 минут. Даже статья в Википедии , которую можно использовать в качестве отправной точки, на удивление коротка.
С практической точки зрения HATEOAS в первую очередь включает в себя URL-адреса в ответах, чтобы клиенты могли переходить к желаемому ресурсу, вместо того чтобы переходить к жестко закодированным URL-адресам:
GET /users
...
HTTP/1.1 200 Ok
[
{
name: 'giorgio',
profile: '/users/giorgio'
},
...
]
Вопрос для ответа в этой статье — почему мы должны это делать.
Автостоянки
Презентация Уэйна Ли сравнивает HATEOAS со стоянкой с одним входом, где водителям автомобилей можно узнать, куда идти. У веб-службы старого стиля вместо этого есть несколько входов, и вы должны управлять всеми входящими запросами к каждому из этих входов (URL). Обратная совместимость становится рутиной, поскольку вам нужно сохранить все URL-адреса, которые вы когда-либо поддерживали.
Эта работа также полезна для предоставления убедительных примеров новых требований, которые превосходят старые URL-адреса, предполагая, что они не являются статической частью Api:
- включение пользовательских параметров в URL для замены старого сеансового решения (решение … Читать взломать ).
- Новые профессиональные учетные записи, где данные извлекаются из другого доменного имени, соответствующего более быстрому серверу.
- VIP аккаунты с пользовательским доменным именем.
Этот бесконечный список требований показывает также, как клиент становится все более и более сложным для решения всех случаев; в случае HATEOAS сложность переносится на сервер, который перечисляет только те URL-адреса, которые доступны текущему клиенту.
Примеры запросов / ответов
Алессандро Надалин, паладин REST в Италии, проводит более простое сравнение с HTML-элементами <link> и примером использования кода 201 Created . Когда ресурс создается с помощью POST, вы можете вернуть заголовок Location в своем ответе, чтобы клиент мог перейти по этой ссылке на новый ресурс, а не придумывать URL-адрес, который, в конце концов, сломается:
POST /users HTTP/1.1 201 Created Location: /users/1
Пример HTML заслуживает дополнительного пространства, так как веб-разработчик, скорее всего, знаком с HTML и старыми школьными сайтами, чем со спецификацией HTTP. Это может сделать вас грустным; но это факт жизни: поскольку изучение HTML имеет более низкий барьер входа, чем игра с заголовками HTTP, неизбежно будет больше людей, знающих, как использовать первое, чем второе. Давайте заглушим это еще больше.
Эти старые теги <a>
Для обычного веб-разработчика понимание HATEOAS и многих REST-концепций становится проще, если он усвоит следующий принцип. Этот принцип связан с REST как ответом на SOAP и использованием HTTP в качестве туннеля для других протоколов.
Самая большая распределенная система в мире — это сеть. Сеть надежна и надежна, она хорошо масштабируется. Сеть основана на обмене ресурсами, а не на отправке команд. Когда мы создаем веб-сервисы, давайте скопируем архитектурный стиль Интернета, чтобы заработать его свойства. Разница лишь в том, что клиенты — это машины, а не люди.
Неправильное использование POST поверх GET для получения ресурсов соответствует предупреждению вашего браузера о том, что ему придется повторно отправлять форму после обновления страницы поиска. Неправильное использование GET для неидемпотентных действий приводит к отображению ссылок на удаление, реализованных с помощью <a> (что каждый из нас делал один раз в своей жизни), за которым сразу же последовал сканер Google.
Так к какой концепции сети 90-х относится HATEOAS? Допустим, вы создаете сайт для фермы вашего дяди.
Вы можете создать набор страниц, представляющих все виды животных, которые есть у вашего дяди:
/animals/duck.html /animals/cow.html /animals/pig.html
Затем вы должны распространять знания об этих ссылках, и дать пользователям сайта знать обо всех этих модных страницах. Как и любой веб-разработчик, вы готовите PDF-документы, содержащие спецификации для создания этих URI:
/animals/%s.html #substitute the name of the animal from our list
и вы отправляете его по обычной почте каждому зарегистрированному пользователю .
Это безумие, верно? И это именно то, что делает почти каждый веб-сервис (включая те, которые я разработал сам): шаблоны URL перечислены, чтобы вы могли создать URL-адрес конечного ресурса, не переходя от промежуточных. Эти шаблоны URL публикуются в другом формате, как документация веб-службы, в другом формате.
И не реализует HATEOAS это как канав <a> элемент и ожидает наших пользователей , чтобы построить ссылки сами и поместить их в адресной строке браузера. Конечно, это способ сломать их, когда эти форматы меняются; но это также много работы, если вы сравните это с включением ссылок, чтобы следовать в ответах, как это делал каждый веб-сайт 90-х годов.
HATEOAS — это не панацея, и, безусловно, не единственное, что нам нужно для создания расширяемого веб-сервиса, который не сломал бы клиентов. Тем не менее, это важный сдвиг: мы думаем о том, как достичь ресурса, делая минимальные предположения, вместо случайного ввода конечных точек в нашей строке местоположения.