Связность и HATEOAS

Говорят, что в четко определенной системе RESTful клиентам нужно знать только корневой URI или несколько хорошо известных URI, и клиент должен обнаружить все другие ссылки через эти исходные URI. Я понимаю преимущества (развязанные клиенты) от этого подхода, но недостатком для меня является то, что клиенту необходимо обнаруживать ссылки каждый раз, когда он пытается получить доступ к чему-то, что дает следующую иерархию ресурсов:

/collection1
collection1
  |-sub1
    |-sub1sub1
 |-sub1sub1sub1
         |-sub1sub1sub1sub1
    |-sub1sub2
  |-sub2
    |-sub2sub1
    |-sub2sub2
  |-sub3
    |-sub3sub1
    |-sub3sub2

Если мы следуем принципу "Клиент должен знать только корневой URI", то клиент должен знать только о корневом URI i.e./collection1 выше, а остальные URI должны быть обнаружены клиентами через гипермедиа-ссылки. Я считаю, что это громоздко, потому что каждый раз, когда клиент должен делать GET, скажем, на sub1sub1sub1sub1, если клиент сначала выполнит GET on/collection1 и последующую ссылку, определенную в возвращаемом представлении, а затем сделает еще несколько GET на вспомогательных ресурсах, чтобы достичь желаемый ресурс? или мое понимание о связности совершенно неверно?

С уважением, Суреш

Ответ 1

Вы столкнетесь с этим несоответствием, когда попытаетесь построить REST api, который не соответствует потоку пользовательского агента, который использует API.

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

Если вы попробуете и смоделируете свой REST API как своего рода связанный репозиторий данных и пользовательский интерфейс клиента как независимый набор переходов, вы обнаружите, что HATEOAS довольно болезненным.

Ответ 2

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

рассмотрите, как веб-браузер сохраняет свои закладки. Вероятно, у вас, возможно, есть десять или сотни закладок в браузере, и вы, вероятно, нашли некоторые из них в иерархии страниц, но браузер по-настоящему запоминает их, не требуя запоминания пути, необходимого для их поиска.

Более богатое клиентское приложение может запомнить URI sub1sub1sub1sub1 и повторно использовать его, если он все еще работает. Вероятно, он все равно представляет одно и то же (он должен). Если он больше не существует или не работает по какой-либо другой причине клиента (4xx), вы можете повторить шаги, чтобы узнать, можете ли вы найти подходящую замену.

И конечно, что Даррел Миллер сказал: -)

Ответ 3

Я не думаю, что это строгое требование. Насколько я понимаю, легальным для клиента является прямой доступ к ресурсам и начало оттуда. Важно то, что вы не делаете этого для переходов состояний, т.е. Автоматически не выполняете /foo 2 после работы в /foo 1 и т.д. Извлечение/продукты/1234 изначально для редактирования кажется совершенно прекрасным. Сервер всегда может вернуть, скажем, перенаправление на /shop/products/ 1234, чтобы оставаться обратно совместимым (что желательно и для поисковых систем, закладок и внешних ссылок).