Po co HATEOAS po stronie klienta?

Jak obecnie rozumiem, HATEOAS polega w zasadzie na wysyłaniu razem z każdą odpowiedzią linków z informacjami o tym, co robić dalej. Jeden prosty przykład można łatwo znaleźć w Internecie: system bankowy wraz z zasobem konta. Przykład pokazuje tę odpowiedź po żądaniu GET do zasobu konta

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>

Wraz z danymi znajdują się linki informujące, co można zrobić dalej. Jeśli saldo jest ujemne, mamy

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>

Abyśmy mogli tylko dokonać wpłaty. Wszystko w porządku, jeśli korzystamy z Fiddlera lub wysyłamy zapytania za pomocą przeglądarki, możemy łatwo zobaczyć, co można zrobić. Tego rodzaju informacje są przydatne, abyśmy mogli odkryć możliwości API, a serwer jest oddzielony od klienta.

Chodzi jednak o to, że kiedy budujemy klienta, takiego jak SPA z Javascriptem, aplikacja na Androida lub wiele innych rzeczy, nie widzę, jak HATEOAS jest nadal aktualny. Chodzi mi o to: kiedy koduję SPA w javascript, muszę wiedzieć, co można zrobić w interfejsie API, aby napisać kod.

Muszę więc znać zasoby, obsługiwane metody, czego oczekują i co oddają, aby napisać wywołania ajax na serwerze, a nawet aby zbudować interfejs użytkownika. Kiedy tworzę interfejs użytkownika, muszę wiedzieć, że po złożeniu wniosku o konto można na przykład dokonać wpłaty na konto, w przeciwnym razie nie będę mógł podać tej opcji w interfejsie użytkownika. Potrzebuję też znać identyfikator URI, aby dokonać wpłaty w celu zbudowania wywołania ajax.

Mam na myśli to, że kiedy wysyłamy żądania do interfejsu API, łącza pozwalają nam lepiej odkrywać interfejs API i korzystać z niego, ale kiedy budujemy klienta, tworzona przez nas aplikacja nie będzie po prostu patrzeć na łącza, a następnie sama renderować poprawny interfejs użytkownika i wykonaj prawidłowe wywołania ajax.

Jak więc HATEOAS jest ważny dla klientów? Dlaczego w ogóle zawracamy sobie głowę HATEOAS?

tworzona przez nas aplikacja nie będzie po prostu patrzeć na linki, a następnie sama renderować poprawny interfejs użytkownika i wykonywać prawidłowe wywołania ajax

W rzeczywistości, to jest dokładnie to, co hateoas będzie dać UI. Nie to, co jest możliwe, ale kiedy jest to możliwe. Formalne HATEOAS, takie jak HAL , jak stwierdza pytanie, zawiera linki wskazujące, co jest możliwe. Ale kiedy pojawią się te linki, zależy od stanu aplikacji. Tak więc łącza mogą zmieniać się w zasobie w czasie (w oparciu o działania, które zostały już wykonane).

To pozwala nam zbudować interfejs użytkownika, który zawiera wszystkie możliwe stany, ale nie martw się, kiedy te stany staną się aktywne. Na przykład obecność rel="deposit"puszki może bezpośrednio powiedzieć interfejsowi użytkownika, kiedy można renderować make depositformularz. Co następnie pozwala użytkownikowi wprowadzić wartość i przesłać za pomocą linku.

Jak obecnie rozumiem, HATEOAS polega w zasadzie na wysyłaniu razem z każdą odpowiedzią linków z informacjami o tym, co robić dalej

HATEOAS to znacznie więcej niż tylko linki. Jest to „hyper media” jako silnik stanu aplikacji.

W opisie pominięto typ zawartości, formalną definicję hiper-mediów przekazywaną między klientem a serwerem.

HTML jest przykładem hiper-mediów i przykładem tego, dlaczego HATEOS działa. Sama strona HTML jest mechanizmem, który pozwala klientowi (tj. Użytkownikowi) poruszać się po stronie. Przeglądarka z możliwością renderowania HTML-a dla użytkownika w pełni nawigowalną stroną internetową. Nie chodzi tylko o to, że przekazuje linki do innych stron, ale przekazuje je w znaczący sposób, który nadaje kontekst linkom i w sposób, który pozwala przeglądarce zbudować nawigowalną stronę.

A co najważniejsze, przeglądarka może to zrobić dzięki ZEROWemu zrozumieniu samego serwisu. Przeglądarka zna tylko HTTP i HTML. W oparciu o to proste zrozumienie może przedstawić użytkownikowi New York Times do nawigacji.

Dzieje się tak nawet wtedy, gdy „użytkownik” jest innym programem komputerowym. Same hiper-media powinny określać kontekst nawigacji.

Nie musisz budować dynamicznie generowanego interfejsu. Chociaż może być fajnie, nie jest wymagane. Jeśli nie możesz zbudować dynamicznego interfejsu, skorzystaj z łączy i gotowe. Wadą jest to, że ponownie jesteś mocno połączony z backendem i zawiesi się, jeśli coś się zmieni.

Korzystanie z dynamicznego układu może być dość proste:

links.forEach(function(link) {

  switch(link.rel) {

    case 'deposit':
      showDepositButton();
      break;

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

});

Zapisuje cię w kodzie klienta, takim jak:

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

Możesz wprowadzić dozwoloną pozycję ujemną (na przykład pożyczając pieniądze) bez zmiany klienta.