Was bringt HATEOAS auf der Client-Seite?

Nach meinem derzeitigen Verständnis geht es bei HATEOAS im Wesentlichen darum, zusammen mit jeder Antwort Links mit Informationen darüber zu senden, was als Nächstes zu tun ist. Ein einfaches Beispiel ist im Internet leicht zu finden: ein Bankensystem zusammen mit einer Kontoressource. Das Beispiel zeigt diese Antwort nach einer GET-Anforderung an eine Kontoressource

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>

Zusammen mit den Daten gibt es Links, die angeben, was als nächstes getan werden kann. Wenn der Saldo negativ ist, haben wir

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>

Damit können wir nur einzahlen. Das ist alles in Ordnung, wenn wir Fiddler verwenden oder Anfragen mit dem Browser stellen, können wir leicht sehen, was getan werden kann. Diese Art von Informationen ist dann nützlich, um die Funktionen der API zu ermitteln und den Server vom Client zu entkoppeln.

Der Punkt ist jedoch, dass wenn wir einen Client wie ein SPA mit Javascript oder eine Android-App oder viele andere Dinge erstellen, ich nicht sehen kann, wie HATEOAS weiterhin relevant ist. Damit meine ich Folgendes: Wenn ich das SPA in Javascript codiere, muss ich wissen, was in der API getan werden kann, um den Code zu schreiben.

Ich muss also die Ressourcen kennen, die unterstützten Methoden, was sie erwarten und was sie zurückgeben, um die Ajax-Aufrufe an den Server zu schreiben und sogar um die Benutzeroberfläche zu erstellen. Wenn ich die Benutzeroberfläche erstelle, muss ich wissen, dass man nach der Anforderung des Kontos beispielsweise Einzahlungen vornehmen kann oder dass ich diese Option auf der Benutzeroberfläche nicht bereitstellen kann. Außerdem muss ich die URI kennen, um die Einzahlung für den Ajax-Call zu tätigen.

Ich meine, wenn wir Anfragen an die API stellen, können wir die API durch Links besser erkennen und nutzen. Wenn wir jedoch einen Client erstellen, wird die App, die wir erstellen, nicht einfach die Links betrachten und dann von selbst rendern die richtige Benutzeroberfläche und machen die richtigen Ajax-Aufrufe.

Wie wichtig ist HATEOAS für die Kunden? Warum beschäftigen wir uns überhaupt mit HATEOAS?

Die App, die wir erstellen, schaut nicht einfach auf die Links und rendert dann von sich aus die richtige Benutzeroberfläche und führt die richtigen Ajax-Aufrufe aus

In der Tat ist dies genau das, was HATEOAS wird die Benutzeroberfläche geben. Nicht was möglich ist, sondern wann es möglich ist. Ein formaler HATEOAS wie HAL gibt , wie die Frage besagt, Links an, die angeben, was möglich ist. Aber wenn diese Verbindungen auftauchen , hängt vom Zustand der Anwendung. Die Links können sich also im Laufe der Zeit auf der Ressource ändern (basierend auf bereits durchgeführten Aktionen).

Auf diese Weise können wir eine Benutzeroberfläche erstellen, die alle möglichen Status enthält , sich jedoch nicht mit dem Zeitpunkt befasst, zu dem diese Status aktiv werden. Das Vorhandensein von rel="deposit"kann beispielsweise der Benutzeroberfläche direkt mitteilen, ob das Rendern des make depositFormulars in Ordnung ist . Auf diese Weise kann der Benutzer einen Wert eingeben und über den Link übermitteln.

Nach meinem derzeitigen Verständnis geht es bei HATEOAS im Wesentlichen darum, zusammen mit jeder Antwort Links mit Informationen darüber zu senden, was als Nächstes zu tun ist

HATEOAS ist viel mehr als nur Links. Es ist "hyper media" als Motor des Anwendungszustands.

Was in Ihrer Beschreibung fehlt, ist der Inhaltstyp, die formale Definition der Hyper-Medien, die zwischen Client und Server übertragen werden.

HTML ist ein Beispiel für Hyper-Media und ein Beispiel dafür, warum HATEOS funktioniert. Die HTML-Seite selbst ist die Engine, die es dem Client (dh dem Benutzer) ermöglicht, sich durch die Site zu bewegen. Ein Browser, der nur HTML-Code darstellen kann und dem Benutzer eine vollständig navigierbare Website bietet. Es ist nicht einfach so, dass es Links zu anderen Seiten übergibt, sondern es übergibt sie auf eine sinnvolle Weise, die den Links Kontext verleiht und es dem Browser ermöglicht, eine navigationsfähige Site zu erstellen.

Und am wichtigsten ist, dass der Browser dies mit ZERO im Vorfeld des Verständnisses der Website selbst tun kann. Der Browser kennt nur HTTP und HTML. Basierend auf diesem einfachen Verständnis kann es dem Benutzer die New York Times zur Navigation präsentieren.

Dies gilt auch dann, wenn der "Benutzer" ein anderes Computerprogramm ist. Die Hyper-Medien selbst sollten den Kontext der Navigation definieren.

Sie müssen keine dynamisch generierte Schnittstelle erstellen. Obwohl es schön sein könnte, ist es nicht erforderlich. Wenn Sie keine dynamische Schnittstelle erstellen können, verwenden Sie einfach die Links und fertig. Nachteil ist, dass Sie wieder fest mit dem Backend verbunden sind und abstürzen, wenn sich etwas ändert.

Die Verwendung des dynamischen Layouts kann übrigens recht einfach sein:

links.forEach(function(link) {

  switch(link.rel) {

    case 'deposit':
      showDepositButton();
      break;

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

});

Es speichert Sie in Ihrem Kundencode wie:

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

Sie können eine zulässige negative Position implementieren (z. B. durch Ausleihen von Geldern), ohne den Kunden zu wechseln.