© best_vector/Shutterstock.com
Windows Developer
Kolumne: Stropek as a Service

Kolumne: Stropek as a Service


Wer sich heute in Richtung SaaS und Cloud wagt, der hat sich zwangsläufig mit dem Thema Web-APIs beschäftigt. Niemand käme mehr auf die Idee, in einer solchen Umgebung einen Two-Tier Fat Client mit direktem Datenbankzugriff zu entwickeln. Natürlich braucht es eine Service-Schicht in Form eines Web-API, das idealerweise auch als Ganzes oder teilweise für die öffentliche Nutzung durch Kunden und Partner freigegeben wird. Diese Entscheidung fällt nicht schwer. Auch Designeckpfeiler wie HTTPS, JSON und OpenID Connect als Basis für das Kommunikationsprotokoll liegen auf der Hand. Dann beginnen aber schon die Fragen.

In dieser Ausgabe meiner Kolumne möchte ich keine Implementierungsfragen behandeln. Stattdessen möchte ich auf wichtige Designaspekte in Sachen Web-APIs eingehen, die für Einsteiger in das Thema SaaS und Cloud vielleicht nicht alle offensichtlich sind. Sie tragen aber wesentlich zum Erfolg eines API bei. Verwenden Sie die Punkte als Checkliste, um vielleicht noch Lücken in Ihrem API-Design zu entdecken.

Web-APIs sind UX

Bei grafischen Benutzerschnittstellen ist es keine Frage, dass man auf ein klares, sauberes Design achtet. Eingabefelder sind ordentlich angeordnet, auf Einheitlichkeit und Konsistenz wird geachtet, man beauftragt vielleicht sogar einen Designer für den Feinschliff. Auch Web-APIs sind Benutzerschnittstellen und damit Teil der User Experience (UX). Die Benutzer sind interne oder externe Entwicklerteams. Dementsprechend sollten Sie wie beim UI-Design auch der API-Gestaltung ausreichend Aufmerksamkeit schenken (z. B. Namensgebung, URL-Schema, Einhalten von Best Practices, Konsistenz, Standardkonformität etc.). Dokumentierte API-Design-Guidelines, Designreviews auf API-Ebene und Feedbackrunden mit späteren API-Konsumenten sollten wichtige Bestandteile eines cloudbasierten SaaS-Projekts sein.

API-Design, das zu den Szenarien passt

Web-APIs können auf die unterschiedlichsten Arten gestaltet sein. Man kann ein klassisches RESTful Web-API mit CRUD-Operationen für alle Entitäten entwickeln. Das verlagert zwangsläufig Logik in den Client. Die Alternative wären domänenspezifischere API-Endpunkte, die Funktionen auf höherer Abstraktionsebene abbilden. Konzentriert man sich darauf, schränkt man die Cliententwicklungsteams bewusst in ihrer Freiheit ein. OData und GraphQL sind Alternativen, die am anderen Ende des Spektrums sitzen. Sie bieten dem Client sogar eine flexible Abfragesprache, mit der je nach Bedarf selektiert, gefiltert, sortiert, geb...

Windows Developer
Kolumne: Stropek as a Service

Kolumne: Stropek as a Service

Wer sich heute in Richtung SaaS und Cloud wagt, der hat sich zwangsläufig mit dem Thema Web-APIs beschäftigt. Niemand käme mehr auf die Idee, in einer solchen Umgebung einen Two-Tier Fat Client mit direktem Datenbankzugriff zu entwickeln. Natürlich braucht es eine Service-Schicht in Form eines Web-API, das idealerweise auch als Ganzes oder teilweise für die öffentliche Nutzung durch Kunden und Partner freigegeben wird. Diese Entscheidung fällt nicht schwer. Auch Designeckpfeiler wie HTTPS, JSON und OpenID Connect als Basis für das Kommunikationsprotokoll liegen auf der Hand. Dann beginnen aber schon die Fragen.

Rainer Stropek


Wer sich heute in Richtung SaaS und Cloud wagt, der hat sich zwangsläufig mit dem Thema Web-APIs beschäftigt. Niemand käme mehr auf die Idee, in einer solchen Umgebung einen Two-Tier Fat Client mit direktem Datenbankzugriff zu entwickeln. Natürlich braucht es eine Service-Schicht in Form eines Web-API, das idealerweise auch als Ganzes oder teilweise für die öffentliche Nutzung durch Kunden und Partner freigegeben wird. Diese Entscheidung fällt nicht schwer. Auch Designeckpfeiler wie HTTPS, JSON und OpenID Connect als Basis für das Kommunikationsprotokoll liegen auf der Hand. Dann beginnen aber schon die Fragen.

In dieser Ausgabe meiner Kolumne möchte ich keine Implementierungsfragen behandeln. Stattdessen möchte ich auf wichtige Designaspekte in Sachen Web-APIs eingehen, die für Einsteiger in das Thema SaaS und Cloud vielleicht nicht alle offensichtlich sind. Sie tragen aber wesentlich zum Erfolg eines API bei. Verwenden Sie die Punkte als Checkliste, um vielleicht noch Lücken in Ihrem API-Design zu entdecken.

Web-APIs sind UX

Bei grafischen Benutzerschnittstellen ist es keine Frage, dass man auf ein klares, sauberes Design achtet. Eingabefelder sind ordentlich angeordnet, auf Einheitlichkeit und Konsistenz wird geachtet, man beauftragt vielleicht sogar einen Designer für den Feinschliff. Auch Web-APIs sind Benutzerschnittstellen und damit Teil der User Experience (UX). Die Benutzer sind interne oder externe Entwicklerteams. Dementsprechend sollten Sie wie beim UI-Design auch der API-Gestaltung ausreichend Aufmerksamkeit schenken (z. B. Namensgebung, URL-Schema, Einhalten von Best Practices, Konsistenz, Standardkonformität etc.). Dokumentierte API-Design-Guidelines, Designreviews auf API-Ebene und Feedbackrunden mit späteren API-Konsumenten sollten wichtige Bestandteile eines cloudbasierten SaaS-Projekts sein.

API-Design, das zu den Szenarien passt

Web-APIs können auf die unterschiedlichsten Arten gestaltet sein. Man kann ein klassisches RESTful Web-API mit CRUD-Operationen für alle Entitäten entwickeln. Das verlagert zwangsläufig Logik in den Client. Die Alternative wären domänenspezifischere API-Endpunkte, die Funktionen auf höherer Abstraktionsebene abbilden. Konzentriert man sich darauf, schränkt man die Cliententwicklungsteams bewusst in ihrer Freiheit ein. OData und GraphQL sind Alternativen, die am anderen Ende des Spektrums sitzen. Sie bieten dem Client sogar eine flexible Abfragesprache, mit der je nach Bedarf selektiert, gefiltert, sortiert, geb...

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang