HATEOAS Rel - любые стандарты?

Ответ 1

Я считаю, что Язык гипертекстовых приложений (HAL) - это проектный стандарт - попытка стандартизировать эти ссылки между гипермедией.

Это ссылка на проект спецификации JSON http://tools.ietf.org/html/draft-kelly-json-hal-03

Спецификация HAL предусматривает, что "href" соответствует "Target IRI", определенному в спецификации веб-ссылок (RFC 5988).

Существует реализация XML HAL с использованием С# здесь https://github.com/tavis-software

В том же репозитории GitHub, приведенном выше, также содержится пример .Net-реализации RFC 5988.

Ответ 2

Спецификация Web Linking, RFC5988, как было указано в другом ответе, определяет некоторые различные типы отношений ссылок. Но он также поручает IANA создать реестр отношений ссылок и разрешить дальнейшую регистрацию отношений ссылок. Этот реестр, который является окончательным списком ссылок по связям с общественностью, можно найти на iana.org/assignments/link-relations и будет обновляться по мере регистрируются новые отношения.

Обычно используемые отношения в HTTP API включают в себя:

• start (указывает от каждого ресурса обратно к начальной точке API)
• item (указывает из коллекции на элемент, например, со страницы пользователя в Твиттере на твит)
• collection (реверс item)
• previous (следующие четыре предназначены для постраничных ресурсов, например, сборников или многостраничных статей)
• next
• first
• last
• create-form (указывает на коллекцию на ресурс, который описывает, как создавать новые элементы коллекции, например, форму "Новый элемент HTML или XForms")
• edit-form (указывает на элемент на форму для редактирования этого элемента, например, кнопку Изменить твит)

Если ваше желаемое отношение не включено в этот список, оно должно быть URI. Кроме того, рекомендуется сделать этот URI разыменованным URL-адресом http в домене, находящемся под вашим контролем, чтобы клиенты API могли искать документацию для этого отношения, например, http://www.example.com/link-relations#tweets. Обычно отправной точкой API является список коллекций, каждая из которых имеет свое отношение ссылки, которое описывает тип ресурса, который содержит каждая коллекция.

Ответ 3

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

Ответ 4

HAL кажется очень интересным.

Для кого-либо, кто смотрит в эту тему или HATEOAS, необходим браузер HAL. Ознакомьтесь со ссылкой ниже:

Браузер Hal на Heroku

Ответ 5

Прежде чем говорить о стандартах HATEOAS, я хочу подчеркнуть, что в API, реализующем HATEOAS (в настоящее время также известном как Hypermedia API), есть три основных понятия:

• Протокол HTTP. Вы должны соблюдать его ограничения при использовании глаголов и кодов возврата. Вы также должны знать роль заголовков, особенно Content-type, и таких тонкостей, как идемпотентность некоторых глаголов. Смотрите RFC 2616 для более
• Структура URI. Который должен давать только информацию о целевом ресурсе и избегать контекстных данных. Известные плохие примеры, например, включают в URI язык /en/, версию /v01/, формат /json/ или даже глаголы /do-something/. Подробнее об этом в RFC 3986 и в рекомендациях REST
• Контекстные данные, которые можно найти в теле, параметрах запроса или в заголовках

Разработчики библиотек REST имеют строгие рекомендации относительно URI и HTTP, но не имеют универсального стандарта для контекстных данных и того, как они смешиваются с данными приложения в теле запросов JSON.

Вот почему усилия по стандартизации HATEOAS в основном сводятся к созданию спецификаций для media-type. Там есть несколько

• JSON HAL (около 2012 года), как обрисовал в общих чертах Марк Джонс, является самым известным
• Коллекции + JSON (около 2013), которые не привлекли большого внимания
• Verbose (около 2014 г.) пытался объединить все остальные усилия, но известен только специалистам
• Сирена (около 2017 года) имеет около 1 тыс. Звезд на GitHub
• JSON: API (около 2015 года, но все еще в разработке) - это текущая ссылка, с множеством реализаций для его версии 1.0 и поддержкой Стива Клабника, который создал много контента по этой теме.

Относительно вашего исходного вопроса, смотрите ЗДЕСЬ для JSON:API заявления JSON:API о связанных ресурсных ссылках.

Надеюсь, что это поможет всем, кто испытывает те же проблемы в 2019 году.