Существуют ли стратегии для обнаружения служб REST с использованием HATEOAS?


10

При построении службы REST с ограничением HATEOAS очень легко объявить о существовании ресурсов посредством связывания. Вы заходите GETв корень моего сайта, а я отвечаю корневым документом, в котором перечислены все ресурсы первого уровня:

{
    users: { href: "/users" }
    questions { href: "/questions" }
}

Клиенты, которые понимают, как читать эти hrefзначения, могут выполнять GETзапросы к ним и обнаруживать все текущие ресурсы, доступные в приложении.

Это хорошо работает для базовых сценариев поиска, но не указывает, является ли ресурс запрашиваемым. Например, может быть целесообразно выполнить:

GET /users?surname=Smith

Существуют ли какие-либо форматы, которые могли бы выразить эту возможность запроса с достаточным количеством информации, чтобы клиент мог сформировать согласованный запрос без необходимости предварительного знания ресурса?

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

POST /questions

{
    title: "Are there strategies for discovering REST services using HATEOAS?",
    body: "When building a REST service with the HATEOAS constraint, it's very..."
}

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

Существуют ли форматы, которые способны на подобные вещи для клиентов?


2
Проблема с обнаружением REST-сервиса обсуждалась здесь и была дана ответ здесь: stackoverflow.com/questions/9101494/… Простейшее решение - использовать шаблон XHTML с формой, которая будет рассказывать не только о методе, который вы можете использовать, но и структура объекта для отправки через элементы формы (ввод, выбор и т. д.). Клиенты должны иметь только синтаксический анализатор XML, чтобы найти то, что им нужно. Другой способ - с помощью шаблонов URL, но они помогают только с ресурсами, которые принимают строки запроса.
Спойл

Что касается типов контента; это решается с помощью согласования содержимого, которое выполняется в заголовках HTTP. Если сервер не может обслуживать запрошенный тип контента, он должен вернуть ошибку HTTP (например, 300 или 406), указывающую, какие типы контента он может вернуть.
Спойл

Ответы:


1

Как бы вы узнали, какие входные данные являются приемлемыми? То есть, если ваш клиент не имеет предварительных знаний, как бы вы определили семантику «фамилия»? Вы начинаете проникать на территорию, требуя что-то вроде OWL .

Я думаю, что более практично ожидать, что ваши клиенты поймут семантику хорошо известных типов mime; скажем, например, «текст / визитка» для людей.


Я думаю, что использование типа контента - это путь; Я мог бы легко изменить свое приложение для использования application/atomapp+xmlи сделать его доступным для всех клиентов, которые уже понимают этот формат. Вероятно, существует достаточно известных типов контента, чтобы сделать это практическим решением.
Пол Тернер

Я думаю, что комментарий @Spoike - это элегантный подход REST-ian ко второй половине проблемы; даже если клиент знает, что (например) пользователь представлен в виде vCard, ему все равно необходимо знать, в каком подмножестве свойств пользователя доступен поиск.
Стивен Дж. Андерсон

4

Вы можете опубликовать информацию о своих услугах через "WADL"

http://en.wikipedia.org/wiki/Web_Application_Description_Language

Это необязательно, и не все бэкэнд-REST-технологии поддерживают это. Например, Jersey, «официальная» реализация jax-rs в java, поддерживает ее - она ​​может быть сгенерирована автоматически.

Это довольно редко, чтобы увидеть это используется.

Я не знаю больших, использующих это. В общем, у вас есть веб-страница с описанием API.


1
CXF - это еще одна большая реализация Java JAX-RS, которая поддерживает WADL, и вы также начинаете видеть несколько интересных сторонних потребителей WADL.
Донал Феллоуз

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.