Связность и HATEOAS - PullRequest
Новая
       9

Связность и HATEOAS

11 голосов
/ 14 июля 2010

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

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

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

С наилучшими пожеланиями, Суреш

Ответы [ 3 ]

6 голосов
/ 14 июля 2010

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

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

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

4 голосов
/ 15 июля 2010

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

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

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

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

0 голосов
/ 14 июля 2010

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

...