Я впервые с удовольствием пробовал HATEOAS с веб-приложением, которое очень хорошо подходит, потому что пользователь перемещается по дереву «узлов».
Каждый раз, когда пользователь нажимает ссылку наузел, сервер возвращает данные для этого узла и URL-адрес server для данных связанных заметок.
Тело ответа HATEOAS:
{"description":"A good node!",
"category":"IDEAL",
"placement":"Q16","
"_links":{"self":{"href":"http://localhost:8081/position?id=393"}},
"_embedded":{
"parent":
{"placement":"root","category":"IDEAL","_links":{"self":{"href":"http://localhost:8081/position?id=384"}}},
"next_nodes":[
{"placement":"Q13","category":"GOOD","_links":{"self":{"href":"http://localhost:8081/position?id=362"}}}
{"placement":"J10","category":"BAD","_links":{"self":{"href":"http://localhost:8081/position?id=365"}}}
]}}
Когда одинНа странице клиента веб-приложения отображаются данные для узла и его связь с другими узлами, пользователь щелкает, чтобы указать путь к новому узлу, а клиент веб-приложения выбирает данные из URL-адреса следующего сервера, предоставленного HATEOAS.
Это дает обещание HATEOAS - состояние находится в теле ответа, равно как и URL-адреса серверов для следующего состояния, поэтому клиенту веб-приложения никогда не нужно знать ничего, кроме первого корневого URL-адреса.
Однакоэто разваливается (очевидно), когда (очевидно) пользователь говорит «Я хочу URL (клиентский URL) для этого узла, чтобы я мог вернуться к нему».
Для тВ клиенте веб-приложения, использующем HATEOAS, единственным доступным представлением «текущего узла» является ссылка «_self».Что фактически непрозрачно.
Итак, как вы встраиваете это в маршрут / ссылку веб-клиента, чтобы пользователь мог сохранить и вернуться к нему?
В моем приложении, изображенном выше, я вынуждентакже поделитесь идентификатором позиции с веб-клиентом, который затем вынужден восстановить URL-адрес сервера для этой позиции .
Это ожидаемый эффект HATEOAS?На первый взгляд кажется, что это почти полностью сломано, но наверняка есть что-то базовое, что мне не хватает?