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

Question

если я прав HATEOAS ist архитектурный образец и не описывают, КАК клиент должен обнаружить отношения. HATEOAS просто описывают, что сервер должен отправить клиентскому API для обнаружения.

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

Например, без стандарта, такого как hydra/hal/jsonapi, неясно, используют ли json слова "link", "_link", "links", "relations" в документе json для представления отношения.

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

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

управления

Гипермедиа являются представленной строкой.

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

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

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

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

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

Answer 1

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

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

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

• < A HREF = "..."
• < IMG SRC = "..."
• < ссылка HREF = "..."
• < метод формы = "..." действие = "..."

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