2015-10-07 7 views
5

У меня есть этот вопрос, который некоторое время проходит вокруг моей головы. Предположим, что мы структурировали наш проект с бэкэнд и интерфейсом на отдельных уровнях. Таким образом, во внешнем интерфейсе, мы хотим получить костюмер, который поставляется в формате hal+json:Как следует обращаться с Hateoas из интерфейса?

GET /customers/1 HTTP/1.1 
Accept: application/hal+json 
{ 
    "name": "Alice", 
    "links": [ { 
     "rel": "self", 
     "href": "http://localhost:8080/customer/1" 
    } { 
     "rel": "transactions", 
     "href": "http://localhost:8080/customer/1/transactions" 
    }] 
} 

Затем из интерфейса я хочу, чтобы все операции с клиентами. Мой вопрос: как мне получить URL? должно ли оно быть от ответа? или я должен строить его внутренне?

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

если мы идем со вторым вариантом, я не понимаю, как построить этот URL-адрес, если у нас на самом деле нет идентификаторов. Как я могу создавать новые транзакции с клиентами, если renoas заменяет идентификаторы ссылками, и я больше не получил ссылку на объект в теле?

Я думал, что, возможно, сервис должен поддерживать как application/hal+json (ориентированный на пользователей), так и application/json (ориентированный на клиентов), но я не вижу, что так оно и делается в целом.

Как вы думаете?

ответ

3

Определенно первый вариант. А именно, так как HATEOAS является заключительным этапом Richardson Maturity Model, клиенты должны следовать условии ссылки, а не строить URL, сами по себе:

Точка управления гипермедиа является то, что они говорят нам, что мы можем сделать следующий , и URI ресурса, который нам нужно манипулировать, чтобы сделать это. Вместо того, чтобы нам знать, где разместить наш запрос на встречу, элементы управления гипермедиа в ответе сообщают нам, как это сделать.

Какие преимущества это приносит? Я думаю, что, по крайней мере, два:

  • Простая модернизация REST API - серверные разработчики могут изменить идентификаторы URI из ресурсов, не нарушая код на стороне клиента, так как клиенты просто следуйте приведенным ссылкам; Кроме того, серверные разработчики могут легко добавлять новые ссылки.
  • Надежность. Следуя ссылкам, клиентский код никогда не попытается получить доступ к неработающим ссылкам, ошибкам и т. д.

Q: Кроме того, может случиться ситуация, когда мы не имеем ссылку запроса мы хотим сделать?

Это зависит от дизайнера API, чтобы обеспечить наличие всех необходимых ссылок. Разработчик интерфейсов не должен беспокоиться об этом.

Смотрите также:

+0

Что в случае, если у меня есть идентификатор пользователя, который я хочу, чтобы добавить власть? Тогда мне нужно будет сделать запрос GET/пользователям, чтобы получить ссылку от указанных пользователей. Это было бы нормально? Я делаю 2 запроса вместо одного. Спасибо за ваш ответ! – jscherman

+2

вы не должны иметь идентификатор из внешней системы. у вас должен быть URL-адрес. И да, это 2 запроса ... если сервер не достаточно умен, чтобы знать ваши намерения. то, например, он может вставить транзакционное отношение для вас. Один из способов дать вам это намерение - определить потребитель-клиент с заголовком. Но не волнуйтесь слишком много о двух запросах, это очень маленькая цена для оплаты. СЕЙЧАС, если вы являетесь внутренним ... почему вы используете HTTP-api в любом случае? просто перейдите в БД/систему или запись и получите нужные данные. –

+0

Думаю, у меня есть точка. Благодаря! – jscherman

1

HATEOAS (Hypermedia as Engine of Application State) является ограничением архитектуры приложения REST. Вы можете посмотреть на Spring HATEOAS документации к примеру:

https://spring.io/understanding/HATEOAS

Другая ссылка об этом с помощью Spring и AngularJS доступна здесь:

AngularJS and Spring HATEOAS tutorial

Это один, кажется, достаточно хорошо и обрабатывает ваш прецедент.

С уважением, Андре

Смежные вопросы