Frage Wie nützlich / wichtig ist REST HATEOAS (Reifegrad 3)?


Ich beteilige mich an einem Projekt, bei dem einige Senior-Teammitglieder glauben, dass eine REST-API HATEOAS-konform sein und alle Richardsons Reifegrade implementieren muss (http://martinfowler.com/articles/richardsonMaturityModel.html)!

AFAIK die meisten REST-Implementierungen sind nicht HATEOAS-konform und es sollte einen guten Grund geben, warum mehr Leute es nicht tun. Ich kann mir Gründe wie zusätzliche Komplexität, fehlende Frameworks (Server- und Client-Seiten), Performance-Bedenken und ... vorstellen.

Was denken Sie? Hattest du Erfahrung mit HATEOAS in einem realen Projekt?


76
2017-12-02 19:11


Ursprung


Antworten:


Niemand in der REST-Community sagt REST ist einfach. HATEOAS ist nur einer der Aspekte, die einer REST-Architektur Schwierigkeiten bereiten.

Leute machen HATEOAS nicht aus all den Gründen, die du vorschlägst: es ist schwierig. Dies erhöht die Komplexität sowohl auf der Serverseite als auch auf dem Client (wenn Sie tatsächlich davon profitieren möchten).

JEDOCH erleben Milliarden von Menschen die Vorteile von REST heute. Weißt du, wie die "checkout" URL bei Amazon ist? Ich nicht. Aber ich kann jeden Tag auschecken. Hat sich diese URL geändert? Ich weiß nicht, es ist mir egal.

Weißt du, kümmert es dich? Jeder, der einen Bildschirm geschrieben hat, hat den automatischen Client von Amazon gekratzt. Jemand, der wahrscheinlich sorgfältig den Web-Traffic geschnüffelt hat, HTML-Seiten usw. gelesen hat, um herauszufinden, welche Links wann und mit welchen Payloads aufgerufen werden sollen.

Und sobald Amazon seine internen Prozesse und seine URL-Struktur änderte, scheiterten diese hartcodierten Clients - weil die Links kaputt gingen.

Die Gelegenheitssurfer konnten den ganzen Tag problemlos einkaufen.

Das ist REST in Aktion, es wird nur ergänzt durch den Menschen, der in der Lage ist, die textbasierte Oberfläche zu interpretieren und zu intuieren, eine kleine Grafik mit einem Einkaufswagen zu erkennen und zu verraten, was das eigentlich bedeutet.

Die meisten Leute, die Software schreiben, tun das nicht. Den meisten Leuten, die automatisierte Clients schreiben, ist das egal. Die meisten Leute finden es einfacher, ihre Kunden zu reparieren, wenn sie brechen, als die Anwendung zu manipulieren, um nicht an erster Stelle zu brechen. Die meisten Leute haben einfach nicht genug Kunden, wo es darauf ankommt.

Wenn Sie eine interne API sind schriftlich zwischen zwei Systemen mit Experten-Tech-Support und IT auf beiden Seiten des Verkehrs zu kommunizieren, die in der Lage sind, Veränderungen schnell zu kommunizieren, zuverlässig und mit einem Zeitplan für die Änderung, dann REST kauft man nichts. Du brauchst es nicht, deine App ist nicht groß genug und es ist nicht lange genug, um von Bedeutung zu sein.

Große Websites mit großen Benutzergruppen haben dieses Problem. Sie können nicht einfach Leute bitten, ihren Client-Code nach Belieben zu ändern, wenn sie mit ihren Systemen interagieren. Der Entwicklungsplan für Server entspricht nicht dem Zeitplan für die Client-Entwicklung. Abrupte Änderungen an der API sind für alle Beteiligten einfach inakzeptabel, da sie den Verkehr und die Operationen auf beiden Seiten stören.

Ein solcher Vorgang würde sehr wahrscheinlich von HATEOAS profitieren, da es leichter zu versionieren ist, ältere Clients einfacher zu migrieren sind und leichter abwärtskompatibel sind.

Ein Client, der einen großen Teil seines Arbeitsflusses an den Server delegiert und auf die Ergebnisse reagiert, ist viel robuster gegenüber Serveränderungen als ein Client, der dies nicht tut.

Aber die meisten Leute brauchen diese Flexibilität nicht. Sie schreiben Servercode für 2 oder 3 Abteilungen, das ist alles interne Nutzung. Wenn es bricht, reparieren sie es, und sie haben das in ihre normalen Operationen einberechnet.

Flexibilität, ob aus REST oder irgendetwas anderem, erzeugt Komplexität. Wenn Sie es einfach und schnell wollen, dann machen Sie es nicht flexibel, Sie "tun es einfach", und seien Sie fertig. Wenn Sie den Systemen Abstraktionen und Dereferenzierung hinzufügen, werden die Dinge schwieriger, mehr Kesselplatten, mehr Code zum Testen.

Ein Großteil der REST-Anforderungen erfüllt den Punkt "Sie werden es nicht brauchen" nicht. Bis du es natürlich tust.

Wenn Sie es brauchen, dann verwenden Sie es und verwenden Sie es, wie es ausgelegt ist. REST schiebt Dinge nicht über HTTP hin und her. Es war nie, es ist viel höher als das.

Aber wenn Sie REST benötigen und REST verwenden, ist HATEOAS eine Notwendigkeit. Es ist Teil des Pakets und ein Schlüssel zu dem, was es überhaupt funktioniert.


147
2017-12-02 19:31



Ja, ich habe Erfahrung mit Hypermedia in APIs. Hier sind einige der Vorteile:

  1. Erschließbare API: Es mag trivial klingen, aber unterschätzen Sie nicht die Macht einer erforschbaren API. Die Möglichkeit, die Daten zu durchsuchen, erleichtert es den Client-Entwicklern, ein geistiges Modell der API und ihrer Datenstrukturen zu erstellen.

  2. Inline-Dokumentation: Die Verwendung von URLs als Link-Beziehungen kann Client-Entwickler auf die Dokumentation hinweisen.

  3. Einfache Client-Logik: Ein Client, der URLs einfach folgt, anstatt sie selbst zu erstellen, sollte einfacher zu implementieren und zu warten sein.

  4. Der Server übernimmt die Eigentumsrechte für URL-Strukturen: Die Verwendung von Hypermedia entfernt die fest codierte Kenntnis der vom Server verwendeten URL-Strukturen.

  5. Inhalte werden nicht in andere Dienste geladen: Hypermedia ist erforderlich, wenn Inhalte auf andere Server (z. B. ein CDN) heruntergeladen werden.

  6. Versionierung mit Links: Hypermedia unterstützt die Versionsverwaltung von APIs.

  7. Mehrere Implementierungen desselben Service: Hypermedia ist eine Notwendigkeit, wenn mehrere Implementierungen des gleichen Dienstes existieren (und ein Client muss auf mehr als einen von ihnen zugreifen).

Eine ausführliche Erklärung dieser Aufzählungspunkte finden Sie hier: http://soabits.blogspot.no/2013/12/selling-benefits-of-hypermedia.html

(Es gibt eine ähnliche Frage hier: https://softwareengineering.stackexchange.com/questions/149124/what-is-the-benefit-of-hypermedia-hateoas wo ich die gleiche Erklärung gegeben habe)


14
2017-12-11 09:04



Ich denke, eine API kann als RESTful bezeichnet werden, auch wenn die Client-Seite der Anwendung nicht den HATEOAS-Prinzipien folgt. In den meisten Fällen der Kunde muss gegen HATEOAS verstoßen, um die Usability-Anforderungen zu erfüllen. Lassen Sie mich erklären.

HATEOAS beschränkt nicht nur die Server-Seite der Anwendung, sondern auch die Client-Seite. Der Client sollte nicht davon ausgehen, dass eine Ressource eine bestimmte Struktur jenseits der vom Medientyp definierten Struktur aufweist. Der Server sollte eine API anbieten, die einen solchen Client unterstützt.

Nehmen wir an, wir haben das erreicht. Die Client-Seite der Anwendung ist jetzt sehr allgemein, aber höchstwahrscheinlich ist die Benutzererfahrung schlecht, da ohne Kenntnis der Semantik der Ressourcen die Präsentation der Ressourcen nicht auf diese Semantik zugeschnitten werden kann. Wenn die Ressource "Auto" und die Ressource "Haus" denselben Medientyp haben (z. B. Anwendung / json), werden sie dem Benutzer auf die gleiche Weise präsentiert, beispielsweise als eine Tabelle von Eigenschaften (Name / Wert-Paare).

Aber okay, unsere API ist wirklich RESTful.

Angenommen, wir erstellen eine zweite Clientanwendung über dieser API. Dieser zweite Client verletzt die HATEOAS-Ideen und hat fest codierte Informationen über die Ressourcen. Es zeigt ein Auto und ein Haus auf verschiedene Arten.

Kann die API immer noch als RESTful bezeichnet werden? Ich denke schon. Es ist nicht der Fehler der API, dass einer ihrer Kunden HATEOAS verletzt hat.

Ich empfehle, RESTful-APIs zu erstellen, d. H. APIs, für die ein generischer Client implementiert werden kann in der Theorie, aber in den meisten Fällen brauchen Sie etwas fest codierte Informationen über Ressourcen in Ihrem Client, um die Anforderungen zu erfüllen. Versuchen Sie dennoch so wenig wie möglich zu programmieren, um die Abhängigkeiten zwischen Client und Server zu reduzieren.

Ich habe einen Abschnitt über HATEOAS in mein REST-Implementierungsmuster eingefügt JAREST.


5
2017-10-24 16:14



Ich habe HATEOAS in einigen realen Projekten verwendet, aber mit einer anderen Interpretation als Richardson. Wenn das Ihre Chefs wollen, dann sollten Sie es einfach tun. Ich nehme HATEOAS zu bedeuten, dass Ihre Ressourcen einen HTML Doctype, Hyperlinks zu verwandten Ressourcen und HTML-Formulare enthalten sollten, um die Funktionalität für andere Verben als GET verfügbar zu machen. (Dies ist, wenn der Accept-Typ text / html ist - andere Inhaltstypen erfordern diese Extras nicht.) Ich weiß nicht, woher die Überzeugung stammt, dass alle REST-Ressourcen in Ihrer gesamten Anwendung zusammengeklebt werden müssen. Eine Netzwerkanwendung sollte mehrere Ressourcen enthalten, die direkt miteinander verknüpft sein können. Oder warum wird angenommen, dass XML, JSON und andere Typen dem folgen müssen. (HATEOAS ist HTML-spezifisch.)


2
2017-12-02 20:38