WJAX 2017: Web-APIs, einfach oder?

Datum: 20. November 2017
Autor*in: Regina Staller


Wie im letzten Blog von mir erwähnt wurde, habe ich auf der diesjährigen WJAX einen Vortrag über den effektiven sowie effizienten client- und serverseitigen Umgang mit Web-APIs besucht. Gehalten wurde dieser Vortrag von Thilo Frotscher. Die wesentlichen Themen aus dieser Session möchte ich hier gerne noch einmal vorstellen. Besonders im Bereich IBE/Metasuche bin ich schon einmal auf die ein oder andere Problematik gestoßen und habe aus diesem Vortrag viele Ideen und Konzepte mitgenommen, welche ich im Arbeitsalltag anwenden kann.

Der Vortrag behandelte die Herausforderungen und Fallstricke bei der Implementierung und Wartung von Web APIs. Dabei wies Thilo Frotscher zu Beginn der Session auf die „Seven Fallacies of Distributed Computing“ (Deutsch, 1994) hin:

  1. The network is reliable.
  2. Latency is zero.
  3. Bandwidth is infinite.
  4. The network is secure.
  5. Topology doesn’t change.
  6. There is one administrator.
  7. Transport cost is zero.

James Gosling hat diese Fallstricke um einen weiteren Punkt erweitert:

  1. The network is homogeneous.

Diese Irrtümer müssen von jedem API Entwickler bedacht werden. Um diese Fallstricke zu umgehen, darf eine Web-API nicht nur für den Normalzustand entwickelt werden, sondern explizit für den Fehlerfall: Das sogenannte Prinzip des ‚Design for failure‘. Ausfälle, Fehler und Verbindungsprobleme stellen nicht die Ausnahme, sondern die Regel dar. Im Zuge dessen muss jeder API Entwickler eine Strategie für den Fehlerfall definieren, um das System von Beginn an widerstandsfähig zu entwickeln.

Auf der clientseitigen Entwicklung muss deshalb damit gerechnet werden, dass eine Server-Response entweder gar nicht verfügbar sein kann oder man auf die Server-Response sehr lange warten muss. Falls der Client naiv implementiert wurde, wartet man dann schlimmstenfalls für immer auf die Response und die Anwendung wäre komplett blockiert. Der default Connection Timeout des http Protokolls ist standardmäßig unendlich. Dies ist nur wenigen Entwicklern bekannt, wie in der Session aufgekommen ist.

Um diese clientseitige Blockade im Fehlerfall zu umgehen, muss man sich unbedingt Gedanken über Connection- sowie Read-Timeouts, Retry-Konzepte sowie über ein Default-Verhalten der Anwendung im Fehlerfall machen. Bei der Wiederholbarkeit von Requests ist dabei zu bestimmen wann welche Requests wie häufig noch einmal abgefeuert werden können.

Auch hat Thilo Frotscher in diesem Zusammenhang den ‚Circuit Breaker‘ (Sicherungskasten) angesprochen. Um eine Anwendung im Fehlerfall vor einem kompletten Absturz zu bewahren, wird eine Sicherung eingebaut, welche die ‚Überhitzung‘, also die komplette Überlastung des Systems verhindert.

Auch die ‚Bulkheads‘ (Schotten) sind ein wichtiges Konzept für das Prinzip ‚Design for failure‘. Dabei wird die Anwendung im Problemfall „über Wasser gehalten“, d.h. eine Teilfunktionalität bleibt erhalten. Die Systembestandteile werden sozusagen voneinander möglichst weitgehend isoliert. Dies kann man durch den redundanten Einsatz von Hardware, der Bindung bestimmter Prozesse an bestimmte CPUs, der Trennung von Business-Funktionalität auf diverse Server-Cluster sowie durch die Verteilung von Funktionalität auf mehrere Thread-Pools erreichen.

Zudem erwähnte der Speaker den Einsatz von Sicherheitsmaßnahmen in der Web-API Entwicklung. Bei der Authentifizierung sprach er sich für JSON Web Tokens sowie OAuth aus. Des Weiteren hat sich neben der Verschlüsselung über SSL/TLS folgende Sicherheitsmaßnahme bewährt: Kein Einsatz von API Keys in der URL.

Die hier genannten Punkte stellen nur einen Bruchteil der zu bedenkenden Maßnahmen in der ‚Design for failure‘ API Entwicklung dar. Es gibt natürlich noch weitere Konzepte, welche hierbei berücksichtigt werden müssen bzw. können. Alles in allem ein sehr interessanter Vortrag, der wichtige Ansätze für die Web-API Entwicklung lieferte.


Dieser Artikel wurde verschlagwortet unter:


Kommentare

Selber kommentieren:






Weitere Beiträge zum Thema Technologie


Apple Touch Icons nutzen

Autor*in: Bastian Schwarz


Projekte // Technologie // User Experience & Design


Ich habe mal ein wenig recherchiert und möchte hier das Ergebnis mitteilen. Die Apple Touch Icons können generell benutzt werden um Apps oder Webseiten auf z.B. den Startbildschirm zu pinnen. Ist bei der Webseite dann ein solches Icon hinterlegt wird das „Lesezeichen“ mit ihm hinterlegt und man erhält so einen schönen Wiedererkennungswert. Generell sollten die …


Beitrag lesen
17
OKT
12

JAX 2015 – Tag 1

Autor*in:


Technologie


Dieses Jahr ging’s für mich zum ersten Mal nach Mainz zur JAX – der größten Java-Konferenz in Deutschland. Nach zwei Teilnahmen bei der WJAX in München, der kleinen Schwester der JAX, war ich natürlich gespannt, was in Mainz auf mich zukommen würde. Kontext und Schlüssel-Themen im Überblick Sebastian Meyen, Chefredakteur des Java-Magazins, eröffnete die Konferenz …


Beitrag lesen
24
APR
15

Marzipano – a 360° viewer for the modern web

Autor*in: Benjamin Hofmann


Projekte   //   Strategie & Konzeption   //   Technologie


Marzipano Alt
Beschreibungstext Beschreibungstext

Im Zuge einer Aufwandsschätzung für zur Einbindung von 360°-Panoramen, die vom Kunden selbst erstellt und eingebunden werden können, bin ich auf Marzipano gestoßen. Ein Skript, welches das mit Bravour erledigt und mit 55 KB Dateigröße (komprimiert) auch einen relativ kleinen Footprint hat. Das Tool wird übrigens von Mitarbeitern von Google entwickelt, ist aber kein offizielles …


Beitrag lesen
16
JAN
17

kraken.io: Einfaches Web Interface zur Bild-Optimierung

Autor*in: Benjamin Hofmann


Technologie // User Experience & Design


Auch wenn wir inzwischen vermehrt skalierbare Iconfonts oder SVG-Grafiken einsetzen, so kommt es doch immer wieder vor, dass wir auch Rastergrafiken in den Formaten JPEG, GIF oder PNG im Layout einsetzen. Was wir aber allzu oft übersehen ist, dass man bei diesen einiges an Dateigröße sparen kann. Und das kommt inzwischen nicht nur denen zugute, …


Beitrag lesen
28
NOV
14