[Первоначально опубликовано на http://intercoolerjs.org/2016/05/08/hatoeas-is-for-humans.html]
TLDR
- HATEOAS на самом деле представляет собой простую концепцию: сервер отправляет как данные, так и сетевые операции с этими данными клиенту, который не имеет специальных знаний о данных.
- Эта простая, но мощная идея была утеряна, потому что ее обычно рассматривают с точки зрения машин и API, а не с точки зрения людей и HTML.
- Люди имеют уникальную возможность воспользоваться преимуществами HATEOAS так, как машины (пока) не могут.
ХАТЕОАС — Что?
HATEOAS, пожалуй, наименее понятный аспект REST и часто является объектом откровенной ненависти вполне разумных, компетентных разработчиков. Это очень плохо, и это в основном связано с тем, что концепции HATEOAS и REST были применены к API (первоначально XML, затем JSON), а не к тому, где они изначально возникли: к людям и HTML в Интернете.
Давайте посмотрим, смогу ли я дать простое (хотя и неполное) объяснение того, что такое HATEOAS, а затем объяснить, почему он так хорошо работает с людьми и HTML и почему плохо работает с машинами и JSON.
Начнем с самого начала. Что означает аббревиатура HATEOAS?
Простой!
«Гипермедиа как двигатель состояния приложения»
Хорошо, может быть, не так просто. Так что же означает это?
Это означает следующее: все «состояние» (то есть как данные, так и сетевые действия, доступные для этих данных) закодировано в гипермедиа (например, HTML), возвращаемом сервером. Клиенты не знают ничего конкретного о какой-либо конкретной конечной точке сети: как данные, так и сетевые операции, доступные для этих данных, поступают с сервера.
Важный момент, повторюсь еще раз: и данные, и сетевые операции с этими данными поступают с сервера вместе, в гипермедиа.
Звучит немного объектно-ориентированно, не так ли?
HTML — HATEOAS для людей
Давайте рассмотрим пример, который поможет конкретизировать эту идею. Вместо того, чтобы использовать пример API (что, к сожалению, делает даже статья HATEOAS в Википедии), давайте рассмотрим что-то еще более простое: немного HTML. В конце концов, HTML — это самая распространенная и успешная гипермедиа в мире.
Рассмотрим следующий фрагмент HTML, полученный с сервера, скажем, в следующей конечной точке: /contacts/42:
<div>
<div>
Name: Joe Blow
</div>
<div>
Email: [email protected]
</div>
<div>
<a href="/contacts/42/edit">Edit</a>
<a href="/contacts/42/email">Email</a>
<a href="/contacts/42/archive">Archive</a>
</div>
</div>
Этот фрагмент HTML, как вы заметите, кодирует как данные для контакта, так и действия, доступные для этих данных (редактирование, отправка по электронной почте и архивирование) в виде ссылок. Клиент (браузер) ничего не знает о контактах, он знает только, как взять этот HTML и отобразить его как некий пользовательский интерфейс для взаимодействия с человеком. Это, конечно, не самая эффективная кодировка этих данных, к тому же она перемешана с каким-то другим мусором, но это нормально. Этот другой мусор оказался довольно полезным на стороне клиента, так что давайте пока оставим его без внимания.
Это означает, что веб-приложение, которое общается с помощью HTML, естественным образом удовлетворяет ограничению HATEOAS REST, и никому не нужно много думать об этом.
Если вы когда-либо создавали традиционное веб-приложение, поздравляю, вы реализовали HATEOAS лучше, чем 99% всех разработчиков API.
Следует отметить, что, к сожалению, сам традиционный HTML несколько ограничен в количестве HTTP-методов (в основном GET и POST) и действий пользователя (клики и отправка форм), которые он допускает, что затрудняет реализацию всех преимуществ REST. .
К счастью, intercooler.js, помимо многого другого, исправляет обе эти проблемы с помощью атрибутов ic-put-to, ic-delete-from и т. д. и атрибутов ic-trigger, соответственно. Это дает вам гораздо более богатую и полную программную инфраструктуру для создания веб-приложения REST-ful на основе HTML.
Вы должны использовать его. 😉
Почему скрежет зубов?
Как бы то ни было, мы видим, что, несмотря на все эти причудливые формулировки, HATEOAS почти по-идиотски легко реализовать, просто используя HTML.
Откуда тогда вся ненависть и неразбериха вокруг меня?
Чтобы понять почему, давайте посмотрим на пример с HATEOAS Wikipage:
<?xml version="1.0"?>
<account>
<account_number>12345</account_number>
<balance currency="usd">100.00</balance>
<link rel="deposit" href="http://somebank.org/account/12345/deposit" />
<link rel="withdraw" href="http://somebank.org/account/12345/withdraw" />
<link rel="transfer" href="http://somebank.org/account/12345/transfer" />
<link rel="close" href="http://somebank.org/account/12345/close" />
</account>
Это XML API, удовлетворяющий требованиям HATEOAS, поскольку все действия в учетной записи кодируются в виде элементов ссылок. И это здорово, насколько это возможно. Вы получаете Золотую звезду REST за этот API.
Но подумайте, что потребляет эти данные: какой-то клиентский код, возможно, от имени еще одного (толстого или веб-клиента) в будущем, или, возможно, автоматизированный скрипт. Как бы то ни было, с этим, скорее всего, имеет дело код, а не человек.
Что он может сделать со всеми этими действиями? Действия, заметьте, динамические, но сам скрипт, вероятно, нет: ему нужно либо обработать все возможные действия, либо передать их человеку для обработки, верно?
И это доходит до сути проблемы: у кода (пока) нет агентства.
Он не может разумно решить, что делать перед лицом новых и неожиданных действий. Кодировщик, пишущий код, может обрабатывать все возможные действия (сложно) или передавать их человеку где-то еще (тоже сложно).
На самом деле, код, скорее всего, обработает несколько действий и просто проигнорирует остальные, так что вся эта работа для Gold REST Star, к сожалению, будет потрачена впустую.
Агентство как услуга (AAAS)
Так вот, люди не очень хороши, но (но!) одна вещь, в которой мы довольно хороши, — это свобода воли. Мы можем принимать решения в новых и новых ситуациях, разбираться в несколько хаотичной среде и узнавать что-то новое.Мы можем понять, когда появляется новое действие, связанное с некоторыми данными, если мы хотите предпринять это действие.
Это просто то, что мы делаем.
Мне нравится переворачивать отношения клиент-сервер и рассматривать людей-пользователей программной системы как предоставляющих агентство как услугу (AAAS) для сервера.
Программное обеспечение сервера знает все о данных и о том, какие действия доступны с этими данными, но понятия не имеет, что, черт возьми, делать. К счастью, эти в остальном неуклюжие люди появляются и будут тыкать и подталкивать сервер, чтобы предоставить помощь серверу, в которой он так отчаянно нуждается. Сервер, конечно, хочет говорить с людьми на языке (гипермедиа), который люди находят приятным или, по крайней мере, терпимым.
И этот язык — HTML.
Итак, вы можете видеть: система, удовлетворяющая HATEOAS, бесполезна, если гипермедиа не потребляется чем-то с агентурой. Это люди, поэтому для того, чтобы HATEOAS была эффективной, гипермедиа должна быть гуманной.
Опять же, это HTML. Я не осознавал, насколько это особенное, пока не начал писать веб-приложения на 20-м году жизни.
Когда у нас будет сильный ИИ, возможно, ситуация изменится. Но это то, что мы имеем сегодня.
Итак, как мы должны говорить с машинами?
Ну и хорошо. Но как быть с машинами? Нужно написать интеграцию, скрипты, парсинг и толстые клиенты, и все они также должны взаимодействовать с серверами, верно?
Это, конечно, правильно, и, не стыжусь признаться, я не уверен, какой здесь правильный ответ и есть ли он вообще.
REST-minus-HATEOAS во многих случаях работает нормально. Конечные точки в стиле RPC когда-то были популярны и, похоже, снова становятся популярными. Все они кажутся мне достаточно работоспособными.
Но в чем я убежден и в чем я надеюсь убедить вас, так это в том, что HATEOAS в значительной степени тратится на машины.
HATEOAS для людей.
