Стоит ли достигать HATEOAS для обслуживания веб-сервисов в реальном мире?

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

Чтобы проиллюстрировать это, я беру этот пример из книги Rest In Practice о заказе кофе: -

<order xmlns="http://schemas.restbucks.com">
 <location>takeAway</location>
 <item>
 <name>latte</name>
 <quantity>1</quantity>
 <milk>whole</milk>
 <size>small</size>
 </item>
 <cost>2.0</cost>
 <status>payment-expected</status>
 
</order>

В принципе, это позволяет потребителю произвести платеж, определенный тегом . Однако на самом деле потребителю по-прежнему необходимо знать всю семантику вызова этой веб-службы, например, какой метод (POST или PUT) использовать, какие параметры запроса использовать в полезной нагрузке для осуществления платежа и т.д... в другом слове, потребитель все еще должен полагаться на документацию WADL, чтобы знать, как сделать этот веб-сервис успешным. Эти теги, вероятно, имеют больше смысла, если все они используют GET на одном конкретном элементе. В противном случае, я действительно не вижу больших преимуществ при определении ссылок здесь... кроме того, что потребитель знает, какие действия они могут вызывать дальше, а затем ссылается на WADL, чтобы определить, как правильно его вызывать.

Моя следующая забота - это возможность получить очень тяжелую полезную нагрузку со всеми тегами . Например, если GET on/projects/1/users возвращает всю информацию пользователя, относящуюся к проекту 1, я предполагаю, что у меня появятся следующие теги: -

<project>
 <users>
 <user id="12" name="mike" ...="">
 <user id="23" name="kurt" ...="">
 <user id="65" name="corey" ...="">
 </user>
 <links>
 
 
 
 
 
 ...
 </links>
</user></user></users></project>

Если в проекте говорится, что у 500 пользователей... не было бы 500 пользовательских ссылок в полезной нагрузке? В противном случае, каков наилучший подход при перепроектировании моих веб-сервисов для решения этой ситуации? Или это приемлемо в реальном мире?

Любые мысли или предложения здесь очень ценятся. Спасибо.

4 ответа

Чтобы понять, почему это правильно, представьте свой API без подхода HATEOAS: вам придется публиковать каждую возможную схему URI в своей документации (или в вашем WADL, если это ваша вещь), и из этот пункт на вас не может изменить их, не разбивая ваших клиентов.

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

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


В вашем конкретном примере, я думаю, имеет смысл вернуться к HTML. Если вы отобрадите список из 500 ресурсов в HTML, включите ли вы ссылку на каждый ресурс, чтобы пользователи могли получать дополнительную информацию? Вероятно, вы бы это сделали. API REST не сильно отличается: если вы возвращаете список из 500 ресурсов, вам нужно включить 500 ссылок, чтобы пользователи могли получать больше информации о каждом ресурсе.

Ожидание того, что клиенты будут создавать URL-адреса на основе некоторых идентификаторов или имен, будет напоминать просить пользователей вручную вводить URL-адреса в адресной строке браузера.

Вот очень хорошая статья об этом, в частности:

Подобно тому, как файлы HTML ссылаются друг на друга с помощью тегов или так же, как файлы XML связаны друг с другом с XLink, вся передача состояния должна выполняться исключительно как реакция на ссылку, найденную внутри представления


Просто боковая точка в 500 пользовательских вещах: я не эксперт, но я понимаю, что вы можете спокойно разместить разбивку на страницы:

/проект/1/пользователей/страниц/1

<links>
 ...
 
 
 
 
</links>


На самом деле это не ответ, просто некоторые советы по принятию HATEOAS. Вам не нужно включать сотни ссылок, вы можете либо включить 1 ссылку на полный список 500, 1 ссылку на разбитый на страницы подмножество ссылок, либо включить разбиение подмножества в ответе и добавить ссылку следующей страницы.

В ответ на вещь WADL вы должны использовать встроенные средства независимо от вашего формата содержимого, например. В HTML, который будет LINK и A, чтобы указать, что клиент должен делать запросы GET и FORM элементы для запросов POST. Очевидно, что другие форматы и API XLink и XMLHTTPRequest поддерживают HTTP лучше, чем HTML. Вы можете посмотреть http://tools.ietf.org/html/draft-nottingham-link-hint

licensed under cc by-sa 3.0 with attribution.