Гибкость HATEOAS

Question

Я пытаюсь узнать, как лучше использовать REST API, я прочитал о HATEOAS, но не могу полностью понять всю его гибкость.

Может кто-нибудь объяснить, почему он является гибким.

Позволяет рассматривать PayPal HATEOAS API

Вот пример массива ссылок

[ 
    { 
    "href":"https://api.sandbox.paypal.com/v1/payments/payment/PAY-6RV70583SB702805EKEYSZ6Y", 
    "rel":"self", 
    "method":"GET" 
    }, 
    { 
    "href":"https://www.sandbox.paypal.com/webscr?cmd=_express-checkout&token=EC-60U79048BN7719609", 
    "rel":"approval_url", 
    "method":"REDIRECT" 
    }, 
    { 
    "href":"https://api.sandbox.paypal.com/v1/payments/payment/PAY-6RV70583SB702805EKEYSZ6Y/execute", 
    "rel":"execute", 
    "method":"POST" 
    } 
] 

Я понимаю, что мы можем сделать запрос, например, в случае данного примера для платежной информации.

Есть некоторые вопросы

1. Почему мы должны self как тип rel, когда делается запрос приложением он уже знает полный URL этого ресурса, я прав? Почему мы должны дублировать его в массиве ссылок?

2. Колесо гибкости? В этом примере есть три (два без self) rel типов. Как приложение знает все эти типы? Они должны быть жестко закодированы в коде и если, например, был введен новый тип rel, нам все равно нужно добавить логику в код клиента для обработки такого типа rel, поэтому в результате нам нужно обрабатывать типы rel или если ответы API не " Следуйте принципам написания логики HATEOAS, чтобы делать новые запросы.

Я не прав?

Пожалуйста, объясните основную идею этого. Я был бы признателен за любую помощь.
Спасибо.

Answer 1

Я собираюсь ответить на них в обратном порядке, потому что я думаю, что ответ на (2) поможет прояснить (1).

Да, большинство клиентских приложений должны знать, как обращаться с множеством возможных ссылок. Идея состоит в том, чтобы изолировать ваших клиентов от необходимости знать конкретные URI. Если клиенты жестко кодируют или вручную отслеживают URI, то сервер не может когда-либо изменить путь к чему-либо, не разбивая клиентов. Если клиент отслеживает rels, тогда API имеет некоторую гибкость, чтобы изменить то, как выглядят его конечные точки. Клиенту, использующему rels, все равно, что URI изменился.

Причина для того, чтобы оставить self rel, чтобы вы могли использовать его позже. Допустим, вы получаете коллекцию ресурсов из какого-то другого rel. Вы отобразите их на экране. Когда пользователь хочет обновить один из этих ресурсов, как вы это делаете? Выполните всплывающее диалоговое окно со всеми данными, и после того, как они будут обновлены и удалены, вы выполните PUT на URI self, чтобы обновить ресурс.

Кроме того, иногда удобно отвечать клиентам с легким ресурсом. Итак, скажите, вы просите коллекцию из 200 вещей. Вместо того, чтобы возвращать 200 полномасштабных ресурсов, может возникнуть смысл вернуть 200 объектов, которые имеют только свойство name и self rel. Клиент отображает 200 имен, конечный пользователь выбирает один, а затем клиент делает GET на self, чтобы вытащить все данные для этого конкретного ресурса.

Answer 2

HATEOAS позволяет API изменять без изменения клиента. Он следует тому же принципу, что и веб-сайты.Пользователь просто должен знать домашнюю страницу/домен и может выяснить, как его перемещать с помощью гиперссылок.

Я бы только реализовал настоящие услуги RESTful, где эти критерии имеют смысл. Это может создать большую сложность. Прежде всего, вы должны выбрать правильный тип mime контента на сервере. Существует несколько различных предлагаемых форматов, таких как коллекция HAL или JSON, но не стандарт. Клиент также должен быть достаточно умным, чтобы отслеживать URL-адреса на основе ссылок.