Grundlagen zur richtigen API

API Architektur

In diesem Artikel wollen wir uns auf netzwerkfähige APIs beschränken – andere machen bei DooH/Digital Signage nur in speziellen Fällen Sinn. Daher fällt die architektonische Entscheidung leichter. Die Kandidaten für Ihre API sind:

• SOAP („Simple Object Access Protocol“)
• REST („Representational State Transfer“)
• RPC („Remote Procedure Call“)
• HATEOAS („Hypertext as the engine of application state“)

Da sich dieser Artikel in erster Linie nicht an Entwickler richtet, sei vereinfachend nur folgendes angemerkt:

SOAP ist sehr komplex und vielseitig, wird aber meist nur innerhalb gemeinsamer Infrastrukturen eingesetzt und benötigt wegen seiner Struktur mehr Speicher, Leistung und Traffic.

REST ist die am meisten verbreitete Schnittstellentechnologie, die ihre Stärke im Austausch von Daten hat und sehr „schlank“ und einfach zu erlernen ist.

RPC eignet sich mehr dazu, Aktionen auszulösen und stellt dafür stellt ausführbare Prozeduren zur Verfügung.

HATEOAS beinhaltet die Möglichkeit, die Beschreibung und das User Interface gleich mit der API mitzuliefern – die Königsdisziplin. Eine korrekte HATEOAS Implementierung ermöglicht es Änderungen an der API vorzunehmen, ohne dass die Clients neu programmiert werden müssen. HATEOAS ist die höchste Stufe einer REST Implementierung

So könnten Sie eine Datenaustauschschnittstelle via REST anbieten, eventgesteuert reagieren mittels RPC und User Interfaces per HATEOAS realisieren.

Alle vier Technologien haben Vorteile und Nachteile, teilweise werden sie sogar fröhlich vermischt und vielleicht sollten Sie mehrere APIs haben und verschiedene Technologien anbieten. Daneben existieren noch viele weitere Technologien, auf die wir hier nicht eingehen werden.

Digital Signage und Schnittstellen: Software darf keine Insel sein

Eine gute API – endlich

Was ist nun eine gute API? Die Antwort darauf ist ganz einfach: eine gute API ist eine, die sich gut verkaufen lässt. Denn letzten Endes ist eine API aus unternehmerischer Sicht immer ein Produkt. Heutzutage haben Anwender (Kunden!) die Wahl zwischen vielen APIs und oftmals entscheidet die Qualität einer API darüber, welches Produkt zum Einsatz kommt.

Die Chancen Ihrer API verbessern Sie, indem Sie die API nach folgenden Richtlinien entwickeln:

• Richten Sie sich nach dem Outside-In oder Contract-First Approach
• Ihre Zielgruppe sind Developer, denn die müssen mit der API umgehen
• Bietet Sie einfachen Zugang zu sinnvollen Funktionen
• Passen Sie die API sorgfältig in das Softwareuniversum Ihrer Firma ein
• Designen Sie die API und das in einem iterativen Design-Prozess
• Die API ist in sich stringent und nachvollziehbar
• Sie richtet sich nach Standards wo immer möglich
• Ist sicher
• Ist sauber dokumentiert
• Wird regelmäßig gewartet

Digital Signage and Interfaces: API-Basics for Digital Signage

Hinter jedem dieser Punkte stecken eine Menge weiterer Begriffe und Fachwissen – darauf einzugehen fehlt mir hier der Platz und Ihnen die Geduld, ich möchte aber zwei Punkte näher beleuchten:

Der Outside-In Approach vs. Inside-Out und Contract-First.

Beim Inside-Out-Approach betrachtet der Hersteller seine Funktionalität, abstrahiert diese mehr oder weniger und entwickelt dazu eine API. Diese APIs lassen sich üblicherweise schnell und günstig programmieren, orientieren sich aber zu sehr an bestehenden Strukturen und gehen möglicherweise am Markt vorbei. Zumindest sollten Sie einen Experten hinzuziehen, der die Funktionalität und das API Design begleitet und aus einer anderen Perspektive entscheidende Specs definieren kann.

Das Gegenteil ist der Outside-In-Approach, bei dem zunächst einmal analysiert wird, was sich Ihre Kunden wünschen oder bei dem wir Projekte analysieren und deren Anforderungen an APIs und ob Sie diese erfüllen können. Der große Vorteil ist, dass sich diese APIs direkt an Ihren Kundenanforderungen orientieren und das Design auch kundenorientiert ist und damit leicht nutzbar wird. Dem gegenüber steht ein erhöhter Aufwand bei der Anbindung der API an Ihr Backend.

Bei Contract-First sind sie fein raus – hier haben Sie einen Vertrag mit einem Kunden, der gezielt seinen Bedarf teilt und Sie möglicherweise noch für die Programmierung bezahlt. Wenn Sie jetzt noch etwas Marktforschung hinzufügen und gut abstrahieren können, dann können Sie möglicherweise eine gute API und sofortige Rekapitalisierung erreichen. Aber Vorsicht Falle: wir sprechen eben nicht von Custom Feature Development sondern von der Entwicklung einer API, die vielen zur Verfügung stehen soll. Wenn Sie das nicht im Auge behalten, dann landen Sie schnell bei mehreren, ähnlichen APIs und den damit einhergehenden Nachteilen.

API- Design

API Design besteht aus den folgenden Schritten, die aufeinander aufbauen:

• Analyse (Bedarf, Integration, Kosten)
• Architektonische Entscheidungsfindung
• Frontend Design
• Prototyping
• Implementierung
• Veröffentlichung
• Wartung

Durch den Einsatz einer API Beschreibungssprache wie openAPI / Swagger oder RAML lassen sich iterative / agile Ansätze verwirklichen, die schon vor der eigentlichen Programmierung und während der Entwicklung Schwachstellen aufzeigen können. Mitunter können Sie die API, die Backend-Implementierung und die API Clients gleichzeitig entwickeln (lassen), auch von verschiedenen Teams und vor der Fertigstellung der API, was die Time-To-Market Zeit deutlich reduzieren kann und garantiert zur Akzeptanz der API beträgt.

Nebenbei kümmert sich eine solche API Beschreibungssprache auch noch um einen Großteil der Dokumentation und bietet die Überprüfung von Design Entscheidungen ohne weitere Programmierungen.

Persönlich bin ich der Meinung, dass auf eine API Beschreibungssprache nicht verzichtet werden sollte. Derzeit ist openAPI in aller Munde und bei größeren Projekten auch schon in Ausschreibungen enthalten – versuchen Sie also Ihre Schnittstellen mit dieser Sprache zu gestalten.

Was man mit einer API so machen kann

In erster Linie werden Sie APIs erstellen, um mit Kunden Daten auszutauschen. So könnte Ihr Kunde beispielsweise Playlisten direkt aus SAP rüberschicken oder zur Fakturierung die Playbacks der einzelnen Spots auslesen. Jeder Kunde hat hier andere Anforderungen, eine clevere API kann hier aber alles abdecken.

Auch User Interfaces können leicht per API angebunden werden. Mit der API abstrahieren Sie einfach die Funktionalität Ihres Backends und nun können Sie jederzeit angepasste User Interfaces entwickeln, ohne Code in Ihrem Backend anpassen zu müssen.

Erfolgreiche Unternehmen wie Amazon setzen APIs auch innerhalb ihres eigenen Unternehmens ein – damit sind sie immer für zukünftige Anforderungen gerüstet. In Ihrem Fall könnte es z.B. sein, dass ein Kunde 2000 Windows Lizenzen benötigt aber auch 5000 Arduinos im Einsatz hat. Wenn Ihre API zwischen Backend und Player sauber geschrieben ist (ja, sie haben höchstwahrscheinlich schon eine!), dann ist es ein leichtes, die einfacheren Funktionen des Arduino Players per API anzubinden (oder andere SoCs, Raspberry, …).

Auch ein Player selbst kann eine API haben, mittels derer andere Geräte im Intranet zugreifen können. Vielleicht ein Gerät mit RS232 Schnittstelle, das 150m entfernt ist? Kein Problem – RS232 to REST Konverter für unter 100 EUR machen es möglich und schon setzt sich das Gerät per API mit Ihrem Player in Verbindung, um z.B. einen Füllstand oder andere Prozessmetriken zu übermitteln. Ein Sensor steuert den Content je nach Außentemperatur, ein Bildschirm ändert seinen Inhalt, wenn ein Tablett abgestellt wird und ein Kassensystem übermittelt aktuelle Preise.

Mittels APIs können Sie die tollsten Projekte realisieren. Projekte die innovativ sind und wirklich Spaß machen. Oder einfach nur Geld bringen.

Globalisierung, Konsolidierung, Spezialisierung, Multi-Channel, Vermarktung, Personalisierung – ohne APIs werden Sie da in Zukunft nicht mehr viel realisieren können und Ihrem Kunden gegenüber in Erklärungsnot geraten, wieso er/sie denn nicht die mit dem Screen mitgelieferte Software verwenden sollte.

Der API Zug ist längst losgefahren, springen Sie auf bevor er den Bahnhof verlässt!