Внедрение клиента REST, охватывающее ограничение HATEOAS?

Кто-нибудь знает о реализации клиента REST, который охватывает ограничение Hypermedia как механизм состояния приложения (HATEOAS)?

Sun Cloud API кажется хорошим кандидатом, судя по тому, как он документирован, и выражение автора о том, что реализации Ruby, Java и Python были в работе. Но до сих пор я не обнаружил следов кода.

Я ищу что-нибудь - даже частичная реализация будет полезна.

ОТВЕТЫ

Ответ 1

Самое первое, на что вы должны обратить внимание, - это общий веб-браузер. Это стандарт для клиента, который охватывает HATEOAS (по крайней мере до некоторой степени).

Так работает Hypermedia. Это так просто, что это почти больно:

  • укажите в браузере http://pigs-are-cool.org/
  • браузер загружает HTML-страницу, изображения, CSS и т.д.
    • На этом этапе приложение (ваш опыт просмотра) находится в определенном URI.
    • В браузере отображается содержимое этого URI
  • вы видите ссылку в приложении
  • вы щелкните по ссылке
  • браузер следует по ссылке
    • в этот момент приложение находится в другом URI
    • В браузере отображается содержимое нового URI

Теперь для краткого объяснения того, как два термина относятся к опыту просмотра веб-страниц:

  • Hypermedia = HTML-страницы со встроенными ссылками
  • Состояние приложения = то, что вы видите в браузере в любой момент времени.

Итак, HATEOAS фактически описывает, что происходит в веб-браузере, когда вы переходите с веб-страницы на веб-страницу:

HTML-страницы со встроенными ссылками диск, что вы видите в браузере в любой момент времени

Термин HATEOAS - это просто абстракция этого опыта просмотра.

Другие примеры клиентских приложений RESTful:

  • RSS и Feed reader. Они перемещают ссылки, предоставленные им пользователями.
  • Большинство клиентов блога AtomPub. Им нужен только URI для документа служб, и оттуда они узнают, куда загружать изображения и сообщения в блогах, искать и т.д.
  • Вероятно, гаджеты Google (и аналогичные), но они просто браузеры в другой оболочке.
  • Сканеры Интернета также являются клиентами RESTful, но они являются нишевым рынком.

Некоторые характеристики клиентского программного обеспечения RESTful:

  • Клиент работает с любым сервером, учитывая, что он загружается с некоторым URI, и сервер отвечает ожидаемым результатом (например, для клиента блога атома, документа служб Atom).
  • Клиент ничего не знает о том, как сервер разрабатывает свои URI, кроме того, что он может обнаружить во время выполнения
  • Клиент знает достаточно типов медиа и связей, чтобы понять, что говорит сервер (например, Atom или RSS).
  • Клиент использует встроенные ссылки для поиска других ресурсов; некоторые автоматически (например, <img src=) некоторые вручную (например, <a href=).

Очень часто они управляются пользователем и могут корректно называться "пользовательскими агентами", за исключением, скажем, GoogleBot.

Ответ 2

Restfulie - это Ruby, Java и С# framework, целью которого является создание клиентов и серверов, на которых используется HATEOAS. Я не использовал его, но он выглядит интересным.

Вот пример кода из их проекта java:

Order order = new Order();

// place the order
order = service("http://www.caelum.com.br/order").post(order);

// cancels it
resource(order).getTransition("cancel").execute();

Опять же, я не уверен, что это делает, или насколько хорошо это работает на практике, но это кажется интригующим.

Ответ 3

Проблема с REST HTTP и HATEOAS заключается в том, что нет общего подхода к указанию ссылок, поэтому трудно следовать ссылкам, поскольку их структура может измениться от поставщика услуг к другому. Некоторые из них будут использовать <link href="..." />, другие будут использовать проприетарную структуру для ссылок ex. <book href="..." />. Это не похоже на то, что в HTML или атоме ссылка является частью стандартного определения.

Клиент не может знать, что такое ссылка в вашем представлении, поскольку он не знает ваш тип носителя, если нет стандартного или обычного представления ссылки

Ответ 4

Принцип проектирования HATEOAS (REST - это также набор принципов проектирования) означает, что каждый ресурс должен иметь не более одного фиксированного URL.

Все остальное, связанное с этим, должно быть динамически обнаружено с этого URL-адреса через ссылки гипермедиа.

Я только что начал wikipedia stub здесь

Ответ 5

Рич,

Сейчас я работаю над рамкой клиентской стороны RESTful для Джерси. После того, как первоначальный дизайн будет несколько стабилизирован, он будет добавлен в базу кода Джерси и, пройдя через сообщество для обзора, должен в конечном итоге управлять формой клиентской стороны JAX-RS.

В последнее время в списке пользователей Джерси была оживленная дискуссия обо всех вещах RESTful. https://jersey.dev.java.net/servlets/SummarizeList?listName=users

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

Jan

Ответ 6

Spring Framework RestTemplate может использоваться для достижения этой цели. Подробнее см. статью.