Який сенс 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-презенту користувачеві повністю навігаційного веб-сайту. Це не просто те, що він передає посилання на інші сторінки, але він передає їх змістовно, що дає контекст посиланням і таким чином, що дозволяє браузеру створювати навігаційний сайт.

І найголовніше, що браузер може це зробити, використовуючи ZERO наперед розуміння самого веб-сайту. Браузер знає лише HTTP та HTML. Виходячи з цього простого розуміння, він може подарувати користувачеві New York Times користувачеві навігацію.

Це справедливо, навіть якщо "користувач" є іншою комп'ютерною програмою. Сам гіпермедіа повинен визначати контекст навігації.

Вам не потрібно будувати інтерфейс, що динамічно генерується. Хоча це може бути добре, це не потрібно. Якщо ви не можете побудувати динамічний інтерфейс, просто скористайтеся посиланнями, і ви закінчите. Недоліком є ​​те, що ви знову жорстко пов'язані з бекендом, і вийде з ладу, якщо щось зміниться.

Використовувати динамічний макет може бути досить простим btw:

links.forEach(function(link) {

  switch(link.rel) {

    case 'deposit':
      showDepositButton();
      break;

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

});

Це зберігає вас у вашому коді клієнта, як:

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

Ви можете реалізувати дозволену негативну позицію (наприклад, позичивши гроші), не змінюючи клієнта.