Какой смысл с HATEOAS на стороне клиента?

Как я сейчас понимаю, HATEOAS - это, в основном, отправка вместе с каждым ответом ссылок с информацией о том, что делать дальше. Один простой пример легко найти в Интернете: банковская система вместе с ресурсом счета. В примере показан этот ответ после запроса GET к ресурсу учетной записи.

GET /account/12345 HTTP/1.1 HTTP/1.1 200 OK 
<?xml version="1.0"?> 
<account> 
    <account_number>12345</account_number> 
    <balance currency="usd">100.00</balance> 
    <link rel="deposit" href="/account/12345/deposit" /> 
    <link rel="withdraw" href="/account/12345/withdraw" /> 
    <link rel="transfer" href="/account/12345/transfer" /> 
    <link rel="close" href="/account/12345/close" /> 
</account>

Вместе с данными есть ссылки, рассказывающие о том, что можно сделать дальше. Если баланс отрицательный, мы имеем

GET /account/12345 HTTP/1.1 HTTP/1.1 200 OK 
<?xml version="1.0"?> 
<account> 
    <account_number>12345</account_number> 
    <balance currency="usd">-25.00</balance> 
    <link rel="deposit" href="/account/12345/deposit" /> 
</account>

Так что мы можем только внести депозит. Это нормально, если мы используем Fiddler или делаем запросы через браузер, мы можем легко увидеть, что можно сделать. Такая информация полезна для нас, чтобы обнаружить возможности API, и сервер отделен от клиента.

Суть, однако, в том, что когда мы создаем клиента, такого как SPA с Javascript, приложение для Android или многие другие, я не вижу, как HATEOAS продолжает оставаться актуальным. Я имею в виду следующее: когда я кодирую SPA в javascript, я должен знать, что можно сделать в API, чтобы написать код.

Поэтому мне нужно знать ресурсы, поддерживаемые методы, что они ожидают получить и что они возвращают, чтобы записывать вызовы ajax на сервер и даже для создания пользовательского интерфейса. Когда я создаю пользовательский интерфейс, я должен знать, что после запроса учетной записи можно, например, внести в нее депозит, или я не смогу предоставить эту опцию в пользовательском интерфейсе. Кроме того, мне нужно знать URI, чтобы внести депозит для создания вызова ajax.

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

Итак, как HATEOAS важен для клиентов? В любом случае, почему мы беспокоимся о HATEOAS?

приложение, которое мы создаем, не просто просматривает ссылки, а затем само отображает правильный пользовательский интерфейс и делает правильные вызовы ajax

На самом деле, это именно то , что HATEOAS будет давать пользовательский интерфейс. Не то, что возможно, а когда это возможно. Формальные HATEOAS, такие как HAL , как говорится в вопросе, дают ссылки, которые указывают, что возможно. Но когда эти ссылки появляются, зависит от состояния приложения. Таким образом, ссылки могут изменяться на ресурсе с течением времени (в зависимости от уже выполненных действий).

Это позволяет нам создавать пользовательский интерфейс, содержащий все возможные состояния, но не заботиться о том, когда эти состояния станут активными. Например, наличие rel="deposit"может напрямую сообщать пользовательскому интерфейсу, когда можно выполнить визуализацию make depositформы. Который затем позволяет пользователю ввести значение и отправить, используя ссылку.

Как я сейчас понимаю, HATEOAS - это в основном отправка вместе с каждым ответом ссылок с информацией о том, что делать дальше.

HATEOAS - это намного больше, чем просто ссылки. Это «гипермедиа» как двигатель состояния приложения.

Что упущено в вашем описании, так это тип контента, формальное определение гиперссылки, передаваемой между клиентом и сервером.

HTML является примером гипермедиа и примером того, почему HATEOS работает. HTML-страница сама по себе является механизмом, который позволяет клиенту (т.е. пользователю) перемещаться по сайту. Браузер с возможностью отображения HTML предоставляет пользователю полностью ориентируемый веб-сайт. Это не просто то, что он передает ссылки на другие страницы, но он передает их осмысленным образом, который дает контекст ссылкам и таким образом, который позволяет браузеру создавать навигационный сайт.

И самое главное, браузер может сделать это с нулевым пониманием самого сайта. Браузер знает только HTTP и HTML. Основываясь на этом простом понимании, он может представить пользователю New York Times для навигации.

Это верно, даже если «пользователь» - это другая компьютерная программа. Гипермедиа должно определять контекст навигации.

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

Использование динамического макета может быть довольно простым:

links.forEach(function(link) {

  switch(link.rel) {

    case 'deposit':
      showDepositButton();
      break;

    case 'withdraw':
      loadWithdrawForm(link.href);
      showWithdrawButton();
      break;
  }

});

Это сохраняет вас в вашем клиентском коде, как:

if (balance <= 0 && negativeBalanceAllowed === false) {
  showWithdrawButton();
}

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