APIs dienen als Verbindungsstück zwischen Daten und Verarbeitung und erlauben uns damit, Daten im richtigen Kontext als Informationen zu interpretieren. Passende fachliche Themen sind dabei präsenter denn je und erreichen bald auch den Endverbraucher beispielsweise mit dem Digitalen Produktdatenpass, der Kreislaufwirtschaft und Transparenz bei Lieferketten sicherstellen und darüber Auskunft geben soll. Und genau diese Informationen werden von APIs bereitgestellt oder entsprechend verarbeitet. Von technischer Seite sind Standards wie OpenTelemetry nach wie vor Dauerbrenner, ebenso wie der Datenaustausch innerhalb von Systemen. Dafür benötigen wir einen Kommunikationskanal, der von guter Qualität ist, also quasi unsere Erwartungen erfüllt. Diese können funktionale und nicht-funktionale Anforderungen sein, ein strukturierter Inhalt oder die Struktur selbst. SOAP als in die Jahre gekommener Standard ist durch REST abgelöst worden, aber auch die RPC-orientierte Konkurrenz gRPC darf dabei nicht unerwähnt bleiben. Im Rahmen dieses Blogartikels möchte ich daher der Frage auf den Grund gehen, welche der beiden Varianten vielleicht die bessere ist, und dazu etwas genauer hinschauen.
REST, …
oder ausgeschrieben „Representational State Transfer“, verwendet den HTTP-1.1-Standard als Basis für die Kommunikation. Die Übertragung erfolgt dabei immer in der Form, dass ein Request abgeschickt und von der Gegenseite mit einer Antwort quittiert wird. Die Übertragung der Daten erfolgt dabei als einfacher Text. Dabei werden die bekannten HTTP-Methoden wie z. B. GET, POST, PUT, DELETE verwendet, um Daten über verschiedene Endpunkte zu verarbeiten. Diese Daten werden von REST als Ressourcen betrachtet, sodass quasi dienstleistungsorientiert mit einer Anfrage angefordert wird: „Hole mir dies!“ (GET) oder „Lösche jenes!“ (DELETE). Je nach Art der Anfrage müssen Daten im HTTP-Body angehangen werden, entweder in JSON oder XML.
Das sorgt dafür, dass REST unabhängig von der Programmiersprache des Sender- und Empfängersystems ist und wir sprachagnostisch arbeiten können. OpenAPI als Interface Definition Language (IDL) ermöglicht uns die Generierung des benötigten Consumer- und Producer-Codes in Form von Stubs. Damit sparen wir Zeit bei der Implementierung und beim Bugfixing, da wir Methoden und Tests direkt gegen die generierten Typen und Schnittstellen entwickeln können und somit nur einen Teil der Implementierung selbst schreiben müssen. Das Gleiche gilt für Updates und den dazugehörigen Boilerplate-Code. Darüber hinaus ist es sinnvoll, Endpunkte und erwartete Response-Codes beispielsweise via Contract-Testing zu dokumentieren. Um unsere REST-API änderbar zu gestalten, empfiehlt es sich außerdem, über ein Konzept zur Endpunkt-Versionierung in URL, Body oder HTTP-Header nachzudenken. Die Kommunikation über REST versteht sich außerdem als zustandslos. Das bedeutet, dass alle Informationen, die für die Verarbeitung eines Requests nötig sind, in diesem enthalten sein müssen. Ein Beispiel dafür ist die Session-Information nach einer Anmeldung. Nicht die HTTP-Verbindung eines bestimmten Absenders oder vorangegangene Requests gestatten den Zugriff auf eine API, sondern ausschließlich die mitgesendete Session-ID.
HTTP 1.1 vs. HTTP 2.0
Darüber hinaus überträgt HTTP 2.0 den Inhalt nicht im Klartext, sondern binär in Form von Frames. In Verbindung mit der Header-Komprimierung werden die Übertragungszeiten insgesamt verringert. Im Umkehrschluss bedeutet dies natürlich, dass auch alle beteiligten Komponenten, also z. B. Browser, Client- oder Serverbibliotheken, mit HTTP 2.0 umgehen können müssen.
