Актуальные примеры для HATEOAS (REST-архитектура) [закрыто]

140

как все, возможно, заметили, существует множество поддельных / рудиментарных REST-API (которые реализуют HTTP-API и называют его REST без соблюдения требования гипертекста как движка-состояния приложения, что привело к к знаменитой тираде Роя Т. Филдинга , человека, который первым определил REST-парадигму).

Мне не удалось найти никаких практических примеров действительно управляемой гипертекстом REST-реализации вместе с соответствующими определениями медиа-типов для конкретных приложений для переходов состояний.

Есть ли публично доступные примеры таких реализаций?

api rest hateoas pmf
источник
3
Я нахожу это интересным, поскольку многие люди утверждают, что REST «прост», но сам Филдинг говорит, что, хотя это простая архитектура, создать с ее помощью приложение непросто.
aehlke
3
кстати, это должно быть HATEOAS, а не HATEOS, последний плохо гулит.
Дэвид Руссел
1
restcookbook.com/Basics/hateoas
Бен
2
Paypal, кажется, использует его: developer.paypal.com/docs/integration/direct/…
Эндрю Таддеус Мартин
Создал ли когда-нибудь сам Рой Филдинг приложение, использующее HATEOAS?
systemovich

Ответы:

102

Это не реализация в смысле выполнения кода, но мне очень нравится статья « Как получить чашку кофе » на InfoQ. Он описывает процесс заказа кофе в Starbucks как протокол RESTful. Это выходит за рамки типичной вводной статьи о REST «все является ресурсом» и фокусируется на HATEOAS. Настоятельно рекомендуется.

тренделс
источник
5
Книга Джима Уэббера, Саяса Парастатидиса и Яна Робинсона «Отдых на практике» весьма полезна
DomreiRoam
2
Статья прекрасна, но, к сожалению, описываемый в ней API не соответствует строго принципу HATEOAS, поскольку не использует настраиваемые типы мультимедиа. Как клиент узнает, как манипулировать (например, десериализовать, анализировать, отображать) каждым ресурсом, если все является application / xml? Это будет зависеть от некоторых нестандартных способов передачи этой информации, например, документации, предназначенной для чтения людьми.
ygormutti
21

Как насчет Sun Cloud API ? Из введения:

API не предполагает никакой конкретной структуры в пространстве URI. Отправной точкой является URI, предоставленный поставщиком облачных услуг, который идентифицирует само облако. Представление облака содержит URI для других ресурсов в облаке, а также для операций, которые могут выполняться над ними (например, развертывание и запуск виртуальных машин).

Предыстория также может быть полезной.

Рич Аподака
источник
2
Это предыстория, которая помогла мне начать путь HATEAOS.
CyberFonic
3
все ссылки мертвы
Руланд Ван Хеддегем
«Мы сожалеем, что сайт kenai.com закрыт».
Ник Роландо,
@NickRolando, ссылку заменил.
Rich Apodaca
@RichApodaca, ссылка на предысторию мертва.
Васанта Ганеш К.
7

Netflix имеет REST API, основанный на HATEOAS, который включает ссылки как часть ресурсов.

Уилл Сарджент
источник
1
и теперь код статуса 404.
naXa
1
Ссылка @Will Sargent не работает, обновите.
Govi S
Извините, похоже, Netflix снял его и выбрал что-то другое.
Уилл Сарджент
2
Ответы только по ссылкам, как правило, менее актуальны, когда такие ссылки не работают.
nyedidikeke 03
@nyedidikeke, это ссылка, но ответ для этого контекста, вам просто нужно исправить ссылку, отредактировав сообщение!
Аль-Мотафар
3

Разве RESTfulness Sun Cloud API не рассматривается в 4-м пункте Роя:

REST API не должен определять фиксированные имена ресурсов или иерархии (очевидная связь клиента и сервера). Серверы должны иметь возможность управлять своим собственным пространством имен. Вместо этого разрешите серверам инструктировать клиентов о том, как создавать соответствующие URI, например, как это делается в формах HTML и шаблонах URI, путем определения этих инструкций в типах мультимедиа и связях. [Отказ здесь означает, что клиенты принимают на себя структуру ресурсов из-за внеполосной информации, такой как стандарт для домена, который является ориентированным на данные эквивалентом функционального связывания RPC].

Пример 1 Фиксированные имена ресурсов в определенной иерархии:

Из Sun Cloud API: «... представление виртуального ЦОД будет включать представления населяющих его кластеров, которые, в свою очередь, включают представления виртуальных машин в каждом кластере».

Пример 2 внеполосной информации, такой как стандарт для конкретной предметной области:

У вас должно быть содержимое вики-страницы (внеполосная информация), чтобы знать, что «механизм взаимодействия ресурсов» для поля облачных ресурсов «uri» - это GET.

Ежик
источник
2
Вы правы, это вводит в заблуждение. Однако Рой говорит об именах ресурсов в пространстве uri, а не в содержимом типа мультимедиа. Sun может в любое время изменить uri, который используется для доступа к кластеру. Очевидно, он не может изменить термин «кластер» на «группу» внутри представления без создания новой версии типа носителя, но он может изменить URI на что угодно.
Даррел Миллер
4
Мы знаем, что Sun API использует HTTP в качестве унифицированного интерфейса, поэтому клиенту не нужно смотреть на вики-страницу, чтобы узнать, что GET - это действительный глагол для облачного ресурса. Он может либо просто попробовать, учитывая, что он знает, что GET - безопасный глагол, либо он может использовать OPTIONS, чтобы определить, доступен ли он.
Даррел Миллер
3

Я понял, что об этом спросили некоторое время назад, но я попытался продемонстрировать «правильный» поток REST API на простом примере. Я пытался следовать правилам Роя для REST - возможно, это могло бы помочь: Пример API с использованием REST

Джереми
источник