Für Web Services gab es Standards und Profile, die deren Verwendung ausreichend genau beschrieben. Nein, ich möchte nicht die Web Services zurück. Für REST gibt es keinen Standard. Wenn ich wissen möchte, wie ich ein API zu gestalten habe, dann schaue ich in die Dissertation von Fielding, in die HTTP Spezifikation und auf Stackoverflow nach. Diese Quellen werfen aber mehr Fragen auf, als sie beantworten. Daher gibt es unzählige API Stile Guides z.B. von Twitter, Adidas oder dem Weißen Haus, die diese Lücken füllen. Wer einen vollständigen und konsistenten Stile Guide im Unternehmen hat, kann sich glücklich schätzen. Die Anzahl der Guides und die Menge an notwenigen Richtlinien macht die Auswahl oder Erstellung eines Guides nicht einfacher. Allein, dass diese Guides gebraucht werden, zeigt wie komplex REST tatsächlich ist.
Roy Fielding beschreibt in seiner Arbeit "Architectural Styles and the Design of Network-based Software Architectures" aus dem Jahr 2000 in Kapitel 5 einen Architekturstil und nennt diesen „Representational State Transfer“ oder kurz REST. Für die Definition des Stils verwendet er Einschränkungen wie Client Server, Stateless, Cache oder Uniform Interface. Ressourcen, Identifier und Repräsentationen werden ebenfalls erläutert. Die Arbeit ist interessant, gut geschrieben und jedem Software Architekten wärmstens zu empfehlen. Konkrete Hinweise, wie ein REST API zu gestalten ist sind dort nicht zu finden. Fieldings Arbeit ist auch nicht als Standard oder Handbuch gedacht, vielmehr als Vision und Hintergrund für ein Netzwerk basiertes Protokoll auf der Basis des HTTP Standards.
Der HTTP Standard oder besser die HTTP Standards stellen tatsächlich verbindliche Spezifikationen für REST Schnittstellen dar. APIs sollten die HTTP Standards auf jeden Fall einhalten. Zum Beispiel beschreibt die HTTP Spezifikation RFC 7231 in 4.3.4. PUT, das ein Server auf eine PUT Anfrage mit dem Status Code 201 antworten MUSS, falls eine neue Ressource angelegt wurde. Ja, ich habe hier absichtlich PUT verwendet, da man neben POST auch PUT für das Anlegen von Ressourcen verwenden kann. Der HTTP Standard beschreibt das Protokoll, den Aufbau von Nachrichten und die Bedeutung der Methoden. Nicht mehr und nicht weniger. Als Standard für Anwendungsschnittstellen taugen die HTTP Spezifikationen nicht. Dafür wurden diese auch nicht gemacht.
Verfolgt man die Diskussionen zu einfachen REST Design Fragen wie:
- Soll ich POST oder PUT für das Anlegen von neuen Ressourcen verwenden?
- PUT oder PATCH für das Ändern einer Ressource?
- Darf ein GET Request ein Body enthalten?
- Welcher Status Code verwendet man für ....
auf Stackoverflow, so wird deutlich, dass es bei REST zu viel Spielraum für Interpretationen gibt. Es wird Fielding oder die HTTP Spezifikation zitiert und die Bedeutung dann ausgelegt:
- Fielding sagt ...
- Laut Fielding ...
- Ich verstehe die RFC 2762 aber so: ....
- Dann ignorierst du die Empfehlung in HTTP 1/1 Sektion 4.3. ...
Die Abbildung unten zeigt einen Beitrag einer typischen Diskussion auf Stackoverflow, die schnell mal mehr als 1 Million Aufrufe erzielen kann.
Abbildung: Diskussionsbeitrag auf Stackoverflow
Zugegeben, die Auslegung und das Philosophieren über REST macht Spass. Aber bringt einen das wirklich weiter, wenn man eine Schnittstelle zu definieren hat? Die Zeit, die für das Finden einer REST konformen Lösung verloren geht, könnte zielführender für die Entwicklung neuer APIs eingesetzt werden.
Für REST Puristen möchte ich meine Aussagen oben relativieren. Ja, wenn ich mich komplett an Hypermedia halte, einen RESTful Server und einen RESTful Client verwende, der Hypermedia unterstützt und ich die Repräsentationen also die eigentliche Payload als Protokoll sehe, dann benötige ich wirklich nur Fieldings Arbeit und die HTTP Spezifikationen. Zugegeben, meine Kritik ist für Schnittstellen, die wirklich RESTful sind gegenstandslos. Würden die REST Prinzipien besser umgesetzt könnte ich mir die Kritik sparen. Bisher wurde auch so argumentiert: REST ist perfekt, es wird nur nicht richtig umgesetzt. Ich möchte aber anders argumentieren: Die Ideen hinter REST sind zu abgehoben und komplex. Jedenfalls kommen diese selbst 17 Jahre nach Fieldings Arbeit nicht in der Praxis an. Wer ein öffentliches API kennt, welches wirklich RESTful ist, möge bitte in einem Kommentar darauf verweisen.