Das richtige API-Design ist für einen sinnvollen Einsatz entscheidend. Ob Konsument oder Entwickler, beide profitieren davon, wenn Schnittstellen so einfach wie nötig sind und auch große Datenmengen damit performant bearbeitet werden können – vor allem, wenn es um mobile Nutzung geht.

Im Vorfeld des API-Summits vom 19. – 21.06. in München haben wir mit Raphael Schwarz, codeworx, über die Vorteile von gutem API-Design und die Möglichkeiten aktueller Frameworks wie OData und GraphQL für datenzentrierte Services gesprochen.

Datenzentrierte APIs auch für Mobile

Herr Schwarz, welche Einflüsse bergen die größten Gefahren, die User Experience von APIs zu beeinträchtigen?

Raphael Schwarz: Sehr schwierige Frage, die vermutlich nicht pauschal beantwortet werden kann. Eines der häufigsten Probleme, dem ich in meiner täglichen Arbeit als Consultant begegne, sind APIs, die dem Anwender viel zu viel Detailwissen über das zugrunde liegende System abverlangen. Gut designte API sollten simpel, aufs Wesentliche reduziert und weitestgehend selbsterklärend sein.

Welche Möglichkeiten bieten sich Entwicklern, diesen Problemen entgegenzuwirken?

Schwarz: Häufig wird das API-Design von Entwicklern durchgeführt, die sich schon sehr lange mit den zugrunde liegenden Datenmodellen beschäftigen. Aufgrund der jahrelangen Erfahrung neigt man eher dazu, komplexe interne Abhängigkeitsstrukturen als selbstverständlich zu erachten. Für den nicht so erfahrenen, gegebenenfalls auch betriebsfremden Consumer meiner Schnittstelle, ist dies meist nicht so leicht zu erkennen. Essenziell wichtig finde ich dabei einen Reviewprozess, bei dem auch der unverblendete Blick eines Außenstehenden mit einbezogen wird.

Wie helfen Technologien wie OData oder GraphQL, die datenintensiven bzw. -zentrierten APIs in den Griff zu bekommen?

Schwarz: Unschlagbar ist bei solchen Frameworks die Geschwindigkeit, mit der man es schafft, auch relativ komplexe Strukturen in enorm flexibler Form als API zur Verfügung zu stellen. Stichwort Developer Productivity. Durch unterschiedlichste Customizing- und Interception-Mechanismen wird man unzählige Use Cases abdecken können. Wichtig ist nur, die Stärken sowie auch die Schwächen dieser Systeme gut zu kennen, um nicht am Ende in das Customizing für einen unpassenden Use Case mehr Zeit zu investieren, als in eine individuelle Entwicklung der Schnittstelle.

Gerade GraphQL ist eine spannende wie umstrittene Technologie; vor allem die potenziellen Möglichkeiten eines „SQL auf API-Ebene“ stehen in Diskussionen oft im Brennpunkt. Für welche Anwendungsfälle ist GraphQL besonders empfehlenswert?

Schwarz: Ich denke, hauptsächlich hängt die Antwort davon ab, wie viel Abstraktion ich zwischen meinem ER-Modell und meinem Applikationsmodell benötige. Speziell für Datenbanken mit überschaubarer Komplexität, die als Persistenzschicht für verschiedenste Tablet- oder Mobile-Anwendungen dienen, eignen sich Frameworks wie GraphQL natürlich perfekt. Die generelle Verwendbarkeit für ein Projekt hängt aber von so vielen verschiedenen Faktoren ab, dass man hier, denke ich, keine allgemeingültige Regel aufstellen kann.

In Ihrem Workshop zu datenzentrierten APIs auf dem API Summit beschäftigen Sie sich mit der Optimierung von APIs auf große Datenmengen. Welche Tipps können Sie unseren Lesern auf den Weg geben?

Schwarz: Auf diesen Workshop freue ich mich schon ganz besonders, da Optimierung immer schon ein Lieblingsthema war von mir war und ich bei meinen Consultings quer durch Europa immer wieder die gleichen, oder zumindest sehr ähnlichen, Problemursachen entdecke. Kurz zusammengefasst: Zu viel, zu häufig und zu komplex. Meist entsteht das Problemverständnis schon durch das simple Gegenüberstellen von Payload und finaler Visualisierung: Wie viele Requests mit wie vielen Daten ergeben welches Ergebnis? So simpel und doch so häufig unverhältnismäßig, sodass mehrere Megabyte Payload für das Visualisieren einer Tabelle mit zehn Spalten und zwanzig Zeilen bei Weitem keine Seltenheit sind.

Mehr Details zum Thema gibt es von Raphael Schwarz in seinem Workshop „Datenzentrierte APIs“ auf dem API Summit.