как следует обращаться с Hateoas из frontend?

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

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, если у нас на самом деле нет идентификаторов. Как я могу создавать новые транзакции клиентов, если hateoas заменяет идентификаторы ссылками, и у меня больше нет ссылки на объект в теле?

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

Что вы думаете?

2 5
json hateoas

2 ответа:

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

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

Какую пользу это приносит? Я могу придумать по крайней мере два:

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

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

Это до API designer, чтобы гарантировать, что все необходимые ссылки предоставляются. Front-end разработчик не должен беспокоиться об этом.

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

3

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

Https://spring.io/understanding/HATEOAS

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

AngularJS и Spring HATEOAS учебник

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

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

1