Стандарты HATEOAS / архитектурный образец

если я прав, HATEOAS представляет собой архитектурный шаблон и не описывает, КАК клиент должен обнаруживать отношения. HATEOAS просто описывает, ЧТО сервер должен отправить клиенту доступный для обнаружения API.

При внедрении HATEOAS автор API может определить, КАК клиент должен обнаруживать отношения.

Например, без такого стандарта, как гидра / хал / jsonapi, неясно, использует ли json поля «ссылка», «_link», «ссылки», «отношения» в документе json для представления отношения.

С моей точки зрения, это позволило бы мне, как автору API, определить что-то вроде этого (действительный HATEOAS):

Символ «????» представляет собой массив элементов управления гипермедиа.

Элементы управления гипермедиа представлены строкой.

Строка может начинаться с зарезервированных символов «✔», «↯» и «±».

Если строка гипермедиа начинается с «✔», клиенту разрешено выполнять безопасный запрос GET к URL-адресу. URL-адрес следует за символом «✔» и декодируется rot13.

{
    …
    "????": [
       “✔uggc://.../traerf/snagnfl”
    ]
}

С моей точки зрения, это должен быть действительный HATEOAS, или я что-то пропустил?

Конечно, определение собственного стандарта поверх HATEOAS не имеет смысла.


person timg    schedule 02.10.2015    source источник


Ответы (1)


Не существует такого стандартного или архитектурного шаблона, как «HATEOAS». Существует архитектурный стиль REST (Representational State Transfer) (стиль, а не шаблон или что-то еще), который содержит несколько ограничений. Одно из ограничений называется "Гипермедиа как механизм состояния приложения".

Если строка гипермедиа начинается с «✔», клиенту разрешено выполнять безопасный запрос GET к URL-адресу. URL-адрес следует за символом «✔» и декодируется rot13.

Все это не имеет значения (и чистый дизайн), единственное, что имеет значение, это выбранный тип гипермедиа (HTML, Atom, Collection + JSON и т. д.) и элементы управления гипертекстом, такие как:

  • ‹a href="..."
  • ‹img источник = "..."
  • ‹ссылка href="..."
  • ‹метод формы="..." действие="..."

которые определяются типом носителя, а не такими соглашениями, как «если URL-адрес следует за символом» и т. д.

person ioseb    schedule 02.10.2015