HATEOAS: что означает эта аббревиатура?

Передача репрезентативного состояния — более известная как REST — является одной из наиболее важных парадигм программирования современной веб-разработки. Архитектурный стиль, придуманный Роем Филдингом в его диссертации 2000 года, служит основной цели адаптации веб-приложений как можно более оптимальным образом к требованиям современного веба. Поскольку REST приобрел заметную популярность и значимость в последнее время, многие операторы веб-проектов все чаще пытаются реализовать эту концепцию в меру своих возможностей. Однако результаты этих усилий часто не являются «RESTful» или «REST-совместимыми», поскольку некоторые принципы и свойства (например, HATEOAS) не были реализованы должным образом.

HATEOAS — это аббревиатура, которая расшифровывается как «Гипермедиа как двигатель состояния приложений». Этот термин, введенный Филдингом как часть его определения REST, описывает одно из ключевых свойств REST: поскольку стиль архитектуры должен обеспечивать универсальный интерфейс, HATEOAS требует, чтобы клиент REST перемещался по веб-приложению только по URI (Uniform Resource Identifiers) в формате гипермедиа. Если этот принцип реализован, клиенту не требуется никакой дополнительной информации, кроме базового понимания гипермедиа, чтобы иметь возможность взаимодействовать с приложением или сервером.

Отдельные URI предоставляются…

• в виде атрибутов href и src для HTML-документов или фрагментов
• в виде атрибутов/элементов JSON или XML, которые автоматически распознаются соответствующими клиентами.

Благодаря реализации принципа HATEOAS интерфейс REST-сервиса может быть адаптирован в любое время. Это является важным преимуществом данной архитектуры по сравнению с другими структурами приложений, например, основанными на SOAP (Simple Object Access Protocol).

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

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

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

Филдинг определяет четыре свойства для связи между сервером и клиентом:

• Уникальная идентифицируемость всех ресурсов: все ресурсы должны быть идентифицированы URI (уникальным идентификатором ресурса).
• Возможность взаимодействия с ресурсами через представления: если клиент запрашивает ресурс, сервер предоставляет подходящее представление/форму представления (например, HTML, JSON или XML), чтобы клиент мог изменить или удалить исходный ресурс.
• Самоописательные сообщения: каждое сообщение, которым обмениваются сервер и клиент, должно содержать всю информацию, необходимую для его понимания
• Гипермедиа как двигатель состояния приложения (HATEOAS): в конце концов, принцип HATEOAS также является обязательным компонентом REST API. Структура на основе гипермедиа упрощает доступ к приложению для клиентов — для доступа и навигации не требуется дополнительных знаний об интерфейсе.

Таким образом, HATEOAS является одной из элементарных особенностей REST API и незаменим для любого REST-сервиса.

Чтобы сделать концепцию HATEOAS немного более осязаемой, в следующем разделе будет проиллюстрирована ее реализация на примере интернет-магазина. Как это типично для веб-приложений, HATEOAS реализуется путем размещения гиперссылок. Эти перекрестные ссылки между двумя документами или перекрестные ссылки на другую позицию в том же документе отмечаются в HTML-коде следующим образом:

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

Документ, описывающий состояние «корзина», имеет постоянно присвоенный URI, например: ‘https://example.org/shoppingcart’. В том же стиле выполнены URI для отдельных товаров, которые могут быть помещены в корзину — например, ‘https://example.org/item/1’, ‘https://example.org/item/2’ и т. д. Другим возможным состоянием является учетная запись клиента, доступ к которой можно получить непосредственно из корзины и которая может иметь следующий URI: ‘https://example.org/customer/1’. Каждый отдельный документ также содержит ссылки или гиперссылки на действия, которые пользователь мог бы выполнить дальше.

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

В случае REST-сервиса, в котором принцип HATEOAS был соблюден в соответствии с требованиями Fielding, пользователю достаточно знать начальный URI, чтобы иметь возможность воспользоваться предложением в соответствии с планом разработчика.

На основе вышеупомянутой структуры веб-магазина можно также объяснить возможное взаимодействие между клиентом и сервером. Клиентское приложение делает следующий запрос, чтобы получить XML-представление состояния корзины:

Ответ сервера может выглядеть следующим образом: