Connectedness & HATEOAS

Question

Es wird gesagt, dass in einem gut definierten RESTful-System die Clients nur den Root-URI oder wenige bekannte URIs kennen müssen und der Client alle anderen Links durch diese initialen URIs entdecken soll. Ich verstehen, die Vorteile (entkoppelte Kunden) von diesem Ansatz aber der Nachteil für mich ist, dass der Kunde jedes Mal die Links zu entdecken, braucht es den Zugang etwas dh die folgende Hierarchie von Ressourcen gegeben versucht:

/collection1 
collection1 
    |-sub1 
    |-sub1sub1 
|-sub1sub1sub1 
     |-sub1sub1sub1sub1 
    |-sub1sub2 
    |-sub2 
    |-sub2sub1 
    |-sub2sub2 
    |-sub3 
    |-sub3sub1 
    |-sub3sub2 

Wenn wir folgen Der "Client muss nur den Root-URI" Ansatz kennen, dann sollte ein Client nur die root URI ie/collection1 oben kennen und der Rest von URIs sollte von den Clients durch Hypermedia-Links entdeckt werden. Ich finde das umständlich, weil jedes Mal, wenn ein Client ein GET ausführen muss, sagen wir auf sub1sub1sub1sub1, sollte der Client zuerst ein GET auf/collection1 und den folgenden Link in der zurückgegebenen Repräsentation ausführen und dann mehrere GETs auf Unterressourcen ausführen, um das zu erreichen gewünschte Ressource? Oder ist mein Verständnis von Verbundenheit völlig falsch?

Mit freundlichen Grüßen, Suresh

Answer 1

Sie werden auf diese Abweichung stoßen, wenn Sie versuchen, eine REST-API zu erstellen, die nicht mit dem Fluss des Benutzeragenten übereinstimmt, der die API verwendet.

Wenn Sie eine Clientanwendung ausführen, wird dem Benutzer immer ein Startbildschirm angezeigt. Wenn Sie den Inhalt und die Optionen auf diesem Bildschirm mit der Stammdarstellung abgleichen, werden die verfügbaren Links und gewünschten Übergänge gut zusammenpassen. Wenn der Benutzer Optionen auf dem Bildschirm auswählt, können Sie zu anderen Darstellungen wechseln und die Benutzeroberfläche des Clients sollte aktualisiert werden, um die neue Darstellung widerzuspiegeln.

Wenn Sie versuchen, Ihre REST-API als eine Art verknüpftes Datenrepository und Ihre Client-UI als unabhängige Gruppe von Übergängen zu modellieren, werden Sie HATEOAS ziemlich schmerzhaft finden.

Answer 2

Ich glaube nicht, dass das ist die strenge Anforderung. Nach meinem Verständnis ist es für einen Kunden legal, direkt auf Ressourcen zuzugreifen und von dort aus zu starten. Wichtig ist, dass Sie dies nicht für Zustandsübergänge tun, d. H. Nicht automatisch mit/foo2 fortfahren, nachdem Sie auf/foo1 und so weiter gearbeitet haben. Abrufen/Produkte/1234 zunächst zu bearbeiten scheint völlig in Ordnung. Der Server könnte immer, sagen wir, eine Weiterleitung an/shop/products/1234, um rückwärtskompatibel zu bleiben (was auch für Suchmaschinen, Lesezeichen und externe Links wünschenswert ist).

Answer 3

Ja, es ist richtig, dass die Client-Anwendung die Links durchläuft, aber sobald sie eine Ressource entdeckt hat, ist nichts falsch daran, einen Verweis auf diese Ressource zu behalten und sie länger als eine Anfrage zu verwenden. Wenn Ihr Kunde die Möglichkeit hat, sich dauerhaft Dinge zu merken, kann er dies tun.

betrachten, wie ein Webbrowser seine Lesezeichen behält. Sie haben vielleicht zehn oder hundert Lesezeichen im Browser, und Sie haben wahrscheinlich einige davon tief in einer Hierarchie von Seiten gefunden, aber der Browser erinnert sich pflichtbewusst an sie, ohne sich den Pfad merken zu müssen, den er brauchte, um sie zu finden.

Eine komplexere Clientanwendung könnte sich den URI von sub1sub1sub1sub1 merken und ihn wiederverwenden, wenn er noch funktioniert. Es ist wahrscheinlich, dass es immer noch das Gleiche darstellt (es sollte). Wenn es nicht länger existiert oder aus irgendeinem anderen Grund fehlschlägt (4xx), können Sie Ihre Schritte nachvollziehen, um zu sehen, ob Sie einen geeigneten Ersatz finden können.

Und natürlich, was Darrel Miller sagte :-)