Ist das REST API wirklich RPC? Roy Fielding scheint so zu denken

Einer großen Menge von dem, was ich dachte, ich wusste über REST ist offenbar falsch - und ich bin nicht allein. Diese Frage hat eine lange lead-in, aber es scheint nötig zu sein, da die Informationen etwas verstreut. Die eigentliche Frage kommt am Ende, wenn Sie bereits vertraut mit diesem Thema.

Des ersten Absatzes von Roy Fielding ist REST APIs must be hypertext-drivenes ist ziemlich klar, dass er glaubt, seine Arbeit ist weithin falsch interpretiert:

Ich bin frustriert durch die Anzahl der Menschen, die beim aufrufen einer HTTP-basierten Schnittstelle die REST-API. Das heutige Beispiel ist die SocialSite REST-API. Das ist der RPC. Es schreit RPC. Es gibt so viel-Kopplung auf dem display, dass es gegeben werden sollte, ein X-rating.

Fielding geht auf mehrere Attribute einer REST-API. Einige von Ihnen scheinen zu gehen, sowohl gegen die gängige Praxis und gemeinsamen Beratung auf SO und in anderen Foren. Zum Beispiel:

• Einer REST-API eingegeben werden sollten, die keine Vorherige Kenntnis über die ursprüngliche URI (Lesezeichen) und eine Reihe von Standard-Medien-Typen, die angemessen für die Zielgruppe (d.h. es wird erwartet, dass Sie verstanden werden, von jedem client, die möglicherweise verwenden Sie die API). ...
• Einer REST-API muss nicht fest fixiert Ressourcennamen oder Hierarchien (eine offensichtliche Kopplung von client und server). ...
• Einer REST-API sollte verbringen fast alle Ihre aussagekräftigen Aufwand bei der Festlegung der Medien-Typ(en) für die Darstellung von Ressourcen und Fahrt den Zustand der Anwendung, oder bei der Festlegung verlängerter Bezug von Namen und/oder hypertext-fähigen mark-up für die vorhandenen standard-Medientypen. ...

Die Idee "hypertext" eine zentrale Rolle spielt - viel mehr als URI-Struktur oder welche HTTP-Verben bedeuten. "Hypertext" ist in einem der Kommentare:

Wenn ich [Fielding] sagen, hypertext, ich meine die gleichzeitige Präsentation von Informationen und steuert so, dass die Informationen wird die affordance, durch die der Benutzer (oder der Automat) erhält, Entscheidungen und wählt Aktionen. Hypermedia ist nur eine Erweiterung auf das, was der text bedeutet, gehören zeitliche Anker innerhalb eines media-stream; die meisten Forscher haben fiel die Unterscheidung.

Hypertext muss nicht sein, HTML in einem browser. Maschinen können Folgen Sie den links, wenn Sie verstehen, das Datenformat und die relationship-Typen.

Ich vermute an dieser Stelle, aber die ersten beiden oben genannten Punkte scheinen zu vermuten, dass API-Dokumentation für ein Foo-Ressource, die wie folgt aussieht führt zu einer engen Kopplung zwischen client und server und hat keinen Platz in einer ruhigen system.

GET   /foos/{id}  # read a Foo
POST  /foos/{id}  # create a Foo
PUT   /foos/{id}  # update a Foo

Statt, ein agent sollte gezwungen werden, zu entdecken, die URIs für alle Foos, zum Beispiel durch die Erteilung einer GET-Anfrage an /foos. (Diese URIs stellen Folgen dem Muster oben, aber das ist nebensächlich.) Die Antwort verwendet einen media-Typ, der fähig ist zu vermitteln, wie Sie Zugriff auf jedes Element, und was mit ihm getan werden kann, wodurch der Dritte Punkt von oben. Aus diesem Grund API-Dokumentation sollte der Schwerpunkt auf die Erläuterung Interpretation der hypertext enthalten, die in der Reaktion.

Darüber hinaus jedes mal, wenn ein URI zu einem Foo Ressource angefordert, enthält die Antwort alle notwendigen Informationen für einen Agenten zu entdecken, wie Sie Vorgehen, zum Beispiel durch Zugriff auf die assoziierten und übergeordneten Ressourcen über Ihre URIs, oder die durch Maßnahmen nach erstellen/löschen einer Ressource.

Den Schlüssel zu dem ganzen system ist, dass die Antwort besteht aus hypertext, die in einer Medien-Typ, der sich vermittelt, um die agent-Optionen für den übergang. Es ist nicht anders als der Weg, der ein browser arbeitet für den Menschen.

Aber dies ist nur meine beste Schätzung, in diesem besonderen Augenblick.

Fielding geschrieben, eine follow-upin dem er reagierte auf die Kritik, dass seine Diskussion war zu Abstrakt, fehlt in den Beispielen und jargon-Reich:

Andere werden versuchen zu entziffern, was ich geschrieben habe, in einer Weise, die mehr direkte oder gelten einige praktische Anliegen von heute. Ich wahrscheinlich nicht, weil ich bin zu beschäftigt, die Auseinandersetzung mit dem nächsten Thema, der Vorbereitung für eine Konferenz, ein schreiben von einem anderen standard, unterwegs zu einem Fernen Ort, oder einfach nur tun, die kleinen Dinge, die lassen Sie mich das Gefühl, dass ich verdient habe ich mein Gehalt.

So, zwei einfache Fragen für die REST-Experten gibt, mit einer praktischen Denkweise: wie interpretieren Sie das, was Fielding sagt und wie Sie es in der Praxis bei der Dokumentation/Umsetzung von REST APIs?

Edit: diese Frage ist ein Beispiel dafür, wie schwer es sein kann, etwas zu lernen, wenn Sie nicht über einen Namen für das, was du redest. Der name ist in diesem Fall "Hypermedia as the Engine of Application State" (HATEOAS).

InformationsquelleAutor der Frage Rich Apodaca | 2009-07-22