Подтвердить что ты не робот

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

Я только начинаю писать клиентскую реализацию для WebAPI, который я сейчас создаю. API уже использует HATEOAS, поэтому я пишу клиент соответственно. Я использую RestSharp в качестве базы для клиента.

Клиенту передается базовый uri api во время построения ( " https://myapi/start" ), который он запускает запрос, и затем передается набор uris для других доступных ресурсов - авторизация ( " https://myapi/authorize" ) и запрос доступа к токенам доступа ( " https://myapi/tokens" ), чтобы разрешить ему звонить в защищенные ресурсы на api.

Вопрос в том, существуют ли еще какие-либо стандарты для требований rel="" в возвращаемой гипермедиа?

4b9b3361

ОТВЕТЫ

Ответ 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 году.