Strategie und Architektur mit APIs: Ein koordinierter Ansatz

22

Der Aufstieg der Anwendungsprogrammierschnittstelle (Application Programming Interface, API) stellt eine geschäftliche Chance und eine technische Herausforderung dar. Unternehmensverantwortlichen bieten APIs die Gelegenheit, sich neue Umsatzquellen zu erschließen und den Kundenwert zu maximieren. Es ist jedoch Aufgabe von Unternehmensarchitekten, die APIs zu erstellen, mit denen Back End‑Systeme zur Wiederverwendung in neuen Webanwendungen und neuen mobilen Apps verfügbar werden.

Es ist unabdingbar, dass alle Stakeholder verstehen, dass die geschäftlichen Ziele und die technischen Herausforderungen eines API‑Programms eng miteinander in Beziehung stehen. Programmmanager müssen die Verantwortung dafür übernehmen, die wichtigen

geschäftlichen Ziele einer vorgeschlagenen API den Architekten klar mitzuteilen, die diese API erstellen sollen.

Architekten müssen ihrerseits die Verantwortung dafür übernehmen, sich während des gesamten Prozesses für die Bereitstellung einer API‑Infrastruktur und den Entwurf der eigentlichen Schnittstelle klar auf diese Ziele zu konzentrieren. Alle technischen Entscheidungen sollten zur Erstellung einer Schnittstelle beitragen, mit der Entwickler Clientanwendungen erstellen können, die den End Usern wirklichen Nutzen bringen.

In diesem eBook finden Sie Best Practices für den Entwurf ergebnisorientierter APIs als Eckpfeiler für den Erfolg Ihres API‑Programms.

Einführung

Die Unternehmens‑IT des 21. Jahrhunderts macht Datenbanken und Anwendungen verfügbar, die sich zuvor in Silos befanden, sodass Daten und Funktionalität über organisatorische Grenzen hinweg zugänglich sind und in neuen Systemen verwendet werden können. Dieser Trend zeigte sich zuerst in Form der serviceorientierten Architektur (SOA); seine jüngste Auswirkung ist die explosionsartige Zunahme an weborientierten APIs.

Auf einem gewissen Level sind die „Web Services“, die zentraler Bestandteil der SOA sind, das Gleiche wie Web‑APIs. Beide sind Schnittstellen, mit denen Back End‑Systeme zugänglich gemacht werden. Es gibt jedoch einige wesentliche Unterschiede zwischen den beiden Technologien, die sehr wichtig für grundlegende Designentscheidungen sind:

3

Teil 1: Von der SOA zur API

Abbildung 1: Vergleich zwischen SOA und APIs

Integrationsziel

Projektmotivation

Nutzer der Schnittstellen

Intern oder für Partner

IT‑Kosten

Unternehmensarchitekten

Extern, häufig für Kunden

Umsatz des Unternehmens

Anwendungsentwickler

SOA APIs

€€€

• Der hauptsächliche technische Unterschied besteht darin, dass der Schwerpunkt von SOA‑Programmen auf der Erstellung von Web Services liegt, die interne Integrationen zwischen Servern erleichtern, während Web‑APIs die Aufgabe haben, die Erstellung von Webanwendungen und mobilen Apps (die häufig für Kunden bestimmt sind) zu beschleunigen.

• SOA‑Programme werden im Allgemeinen von IT‑Abteilungen durchgeführt und konzentrieren sich auf Kosteneinsparungen, während API‑Programme häufiger von Geschäfts‑entwicklungsabteilungen ausgehen und vor allem neue Umsätze generieren sollen.

• Die meisten SOA‑Projekte werden von und für Unterneh‑mensarchitekten eingerichtet, damit sie heterogene Systeme leichter integrieren und neue IT‑Services leichter bereitstellen können. API‑Programme hingegen sollten sich darauf konzentrieren, die Anforderungen von Anwendungsentwicklern zu erfüllen.

4

Ziele des API-Designs

Teil 1: Von der SOA zur API

Trotz der beschriebenen Unterschiede entstehen viele API‑Programme aus früheren SOA‑Initiativen. Web Services, deren Schwerpunkt auf internen oder partnerbezogenen Integrationen liegt, werden für Entwickler verfügbar gemacht – sowohl innerhalb als auch außerhalb des Unternehmens. Während dieses Prozesses sollten API‑Designer unbedingt berücksichtigen, dass sich die Motivationen und Anforderungen eines API‑Programms deutlich von denjenigen unterscheiden, die zunächst dazu führten, dass Unternehmen ihre IT‑Assets über Web Services zugänglich machten.

Vor diesem Hintergrund können die umfassenden Ziele des API‑Designs allgemein wie folgt definiert werden:

• Ermöglichen von Self‑Service für Anwendungsentwickler und ‑benutzer gleichermaßen

• Reduzieren von Hindernissen für den Zugriff auf wertvolle Unternehmensressourcen

• Behandeln der Anforderungen und Wünsche von Clientanwendungsentwicklern mit Priorität

• Fördern der Zusammenarbeit zwischen und unter internen und externen Ressourcen

• Angehen der Security‑ und Skalierungsprobleme, die entstehen, wenn IT‑Assets für den offenen Markt zugänglich gemacht werden

Vor allem muss der Schwerpunkt des API‑Designs darauf liegen, den geschäftlichen Nutzen der Schnittstelle zu maximieren. In Teil 2 werden wir uns genauer ansehen, wie APIs Nutzen für das Unternehmen schaffen.

Teil 2: Die API-Wertkette

5

Auch wenn APIs möglicherweise für sich betrachtet keinen Wert haben, sind sie sehr wertvoll für das Unternehmen. Dieser Wert wird mithilfe der Back End‑Daten und der Anwendungsfunktionalität geschaffen, die die Schnittstelle unterstützt. Gemäß dieser Sichtweise ist die API einfach ein Hilfsmittel, das es ermöglicht, dass Systeme, die für das Unternehmen sehr wertvoll sind, in Anwendungen wiederverwendet werden, die mit höherer Wahrscheinlichkeit direkten geschäftlichen Nutzen erbringen werden.

Dies ist zwar eine nützliche Perspektive; bei näherer Betrachtung wird jedoch deutlich, dass eine gut entwickelte API einen komplexen und leistungsstarken Konnektor darstellt. Sie verbindet zahlreiche unterschiedliche Unternehmensassets – IT‑Systeme, interne und externe Mitarbeiter, Clientanwendungen und Kunden –, um den

potenziellen Wert dieser Assets effektiver zu realisieren. Dies können wir als die „API‑Wertkette“ bezeichnen.

Es ist wichtig zu verstehen, dass eine API Nutzen auf diese relativ komplexe Weise erbringt, weil es andernfalls ziemlich leicht ist, die Tatsache aus den Augen zu verlieren, dass APIs für den geschäftlichen Nutzen existieren, nicht für die technische Effizienz. Der Nutzen von APIs entsteht direkter als der einer SOA, aber weniger direkt als der des browserbasierten Web, in dem eine Website tatsächliche Vertriebsleads oder Verkäufe vermitteln kann. APIs erzeugen Umsatz auf subtilere Weise, indem sie die im Folgenden genannten unterschiedlichen Assets miteinander verknüpfen.

Abbildung 2: Die API‑Wertkette

Back End‑Systeme API‑Anbieter Anwendungsentwickler Clientanwendungen End User

Beispiele für die Wertschöpfung mit APIs Jede API bietet einen einzigartigen Nutzen. Grundsätzlich können Unternehmen APIs jedoch für Folgendes verwenden:

Direkte Erzeugung neuer UmsätzeEine API kann eine direkte Umsatzquelle sein, wenn Entwickler für den Zugriff bezahlen müssen oder wenn die Schnittstelle verwendet wird, um die unternehmensinterne Erstellung von Anwendungen mit nutzungsbasierter Zahlung zu erleichtern oder um eCommerce zu ermöglichen.

Erreichung von mehr Kunden und höherer Kundenwert APIs vereinfachen den Prozess, mit dem Unternehmen neue Kunden erreichen oder den Wertbeitrag aktueller Kunden erhöhen, indem sie vorhandene Services über neue Plattformen und Geräte anbieten.

Unterstützung von Vertriebs‑ und Marketingmaßnahmen Eine API kann einem Unternehmen auch helfen, seine Produkte und Services zu vermarkten, indem sie die Erstellung ansprechender, immersiver Funktionalität ermöglicht, die Best Practices des Onlinemarketing entspricht.

Stimulieren geschäftlicher und technischer Innovation APIs helfen Unternehmen, neue Systeme, Angebote und Strategien zu entwickeln: Sie reduzieren Innovationshindernisse, indem sie es ermöglichen, Ideen umzusetzen, ohne Back End‑Systeme zu ändern.

6

Teil 2: Die API-Wertkette

7

• Was für Systeme werden verfügbar gemacht, und wo (und bei wem) befinden sie sich?

• Wer ist die Entwicklerzielgruppe, und was für Anwendungen möchte sie erstellen?

„Wer ist die Entwicklerzielgruppe“ ist eine besonders wichtige Frage. Sie ist relevant für die grundlegendste Kategorisierung von APIs: als „privat“ oder als „offen“. Private APIs sind ausschließlich zur Verwendung innerhalb des Unternehmens oder in einigen Fällen durch Partnerunternehmen bestimmt. Offene APIs werden der größeren Community externer Entwickler zur Verfügung gestellt. Diese können dann ihre eigenen Anwendungen mithilfe der Back End‑Ressourcen des Unternehmens erstellen.

Private APIs ähneln vom Konzept her eher Web Services. Im Allgemeinen besteht das Ziel einer privaten API darin, internen Entwicklern, Auftragnehmern und Partnern die effizientere Erstellung von Anwendungen zu erleichtern, die intern oder extern verwendet werden können. Wie bei Web Services sind Kosteneinsparungen häufig die Hauptmotivation, da mit APIs neue Anwendungen kosteneffektiv entwickelt werden können. Viele private APIs werden jedoch verwendet, um öffentlich zugängliche Webanwendungen und mobile Apps zu erstellen, die neuen geschäftlichen Nutzen direkter erzeugen.

Bei offenen API‑Programmen liegt der Schwerpunkt meist auf der Akzeptanz. Unternehmen ermöglichen Entwicklern von Drittanbietern, auf ihre APIs zuzugreifen, um ihre IT‑Assets dem größten möglichen Anwenderstamm zur Verfügung zu stellen. Daher ist die Akzeptanz bei Entwicklern ein wichtiges Maß für den Erfolg einer offenen API. Zwar gibt es weniger offene APIs als private APIs, aber die offenen APIs bieten die größten Geschäftschancen und bedeuten die größten Designherausforderungen und technischen Risiken.

Offene APIs verursachen nicht nur eine Reihe völlig neuer Herausforderungen hinsichtlich des Integrationsdesigns (beispielsweise die Frage, wie Back End‑Systeme für externe Entwickler offengelegt werden können, ohne dass Hacker auf sie zugreifen können), sondern auch neue geschäftliche Risiken. Ein Programm für offene APIs, dessen Konzept nicht gut durchdacht ist, kann dazu führen, dass ein Unternehmen sein Kerngeschäft gefährdet und wichtige Unternehmensassets potenziell für Mitbewerber offenlegt.

Solche geschäftlichen Überlegungen müssen Grundlage technischer Designentscheidungen sein. Wir werden in Teil 3 weiter erörtern, wie Sie geschäftliche Überlegungen mit technischen Entscheidungen koordinieren können.

Treffen von DesignentscheidungenAPI‑Designentscheidungen sollten darauf basieren, welche Elemente die API miteinander verknüpfen soll, d. h. was sich auf den beiden Seiten der Schnittstelle befinden soll, sei es in der IT‑Infrastruktur des Unternehmens oder außerhalb der Unternehmensfirewall. Insbesondere ist es unerlässlich, die folgenden zwei Fragen zu beantworten:

Teil 2: Die API-Wertkette

8

Während mit einer SOA versucht wurde, organisatorische Prozesse zu verbessern, sollen mit API‑Programmen Umsätze des Unternehmens gesteigert werden. Daher müssen sich Designentscheidungen im Hinblick auf APIs deutlich auf die wesentlichen geschäftlichen Strategieziele des API‑Programms im Unternehmen konzentrieren. Bevor Sie mit dem Design einer API beginnen, müssen Sie sich darüber im Klaren sein, welche Probleme mit dem API‑Programm gelöst werden sollen, welche Chancen es nutzen soll und wie dies durchgeführt werden soll. Insbesondere ist es wichtig, die folgenden Fragen zu beantworten:

• Welche Assets sollen zur Verfügung gestellt werden?• Wie soll die API diese Assets zur Verfügung stellen?• Was für Anwendungen sollen anhand der API entwickelt werden?• Wie können Entwickler motiviert werden, die API zu verwenden?• Wie sollen die Anwendungen Nutzen für das Unternehmen schaffen?

Kommunikation und Zusammenarbeit sind der Schlüssel zum Entwerfen einer API, die diesen Herausforderungen und Chancen angemessen ist. Während des gesamten Prozesses von Design, Bereitstellung und Management einer Schnittstelle müssen Programmmanager und API‑Architekten eng zusammenarbeiten, um sicherzustellen, dass sie sich einig sind, was ihre wesentlichen strategischen Ziele sind, wie sie sie erreichen möchten und wie sie die Ergebnisse ihrer Bemühungen bewerten werden. Insbesondere muss Folgendes zwischen den geschäftlichen und den technischen Beteiligten vereinbart sein:

• das Ziel und der ideale Endzustand des Programms• die anfänglichen Aufgaben, mit denen das Unternehmen auf diese Ziele

hinarbeiten kann• die wichtigsten Messdaten, anhand derer der Erfolg gemessen werden soll • die fortlaufenden täglichen Aufgaben, mit denen das Programm seine Ziele

erreichen kann

Teil 3: Koordinieren des API-Designs mit Unternehmenszielen

9

Abbildung 3: Koordinieren von API‑Zielen

Sobald die Kommunikation aufgenommen wurde und Einigkeit über Ziele, Aufgaben und Messdaten herrscht, kann die wirkliche Arbeit des API‑Designs beginnen. Diese werden wir in Teil 4 erörtern.

API-VorreiterAPI-Programmmanager API-Architekt

Ziele Aufgaben Messdaten

EntwicklerzielgruppeGeschäftsleitung

Technische RessourcenUmsatzchancen

Teil 3: Koordinieren des API-Designs mit Unternehmenszielen

Zuweisen eines PatenUm sicherzustellen, dass Geschäftsbereichsleiter und Architekten stets auf demselben Stand sind, benötigt das Programm einen „Paten“, der die häufig auftretende Kluft zwischen technischen Abteilungen, Geschäftsbereichsleitern und Anwendungsentwicklern überbrücken kann. Unternehmen machen häufig den Fehler, diese Rolle einem nicht technisch orientierten Marketingmanager zuzuweisen, aber dieser „API‑Vorreiter“ muss in der Lage sein, die Architektureinschränkungen des Unternehmens zu verstehen und die Begeisterung der Anwendungsentwickler zu teilen.

Die Rolle des Vorreiters besteht darin, klare Kommunikation unter allen Stakeholdern zu erreichen, insbesondere wie folgt:

• Fördern der Akzeptanz des API‑Programms bei Führungskräften und anderen leitenden Entscheidungsträgern

• Sicherstellen, dass API‑Architekten die geschäftlichen Ziele der Programmmanager verstehen

• Unterstützen der Programmmanager, damit sie die technischen Ressourcen und Einschränkungen der Architekten verstehen

• Sammeln von Informationen zu Wünschen und Anforderungen der Entwicklerzielgruppe

10

Einige Anmerkungen zur geschäftlichen API‑StrategieProgrammmanager (oder „API‑Verantwortliche“) müssen – in Zusammenarbeit mit dem API‑Vorreiter des Unternehmens – die Verantwortung dafür übernehmen, eine klare geschäftliche API‑Strategie zu entwerfen und sie den Entscheidungsträgern auf Führungsebene ebenso mitzuteilen wie den Architekten und Entwicklern, die die technische Seite der Strategie umsetzen sollen.

Der erste Schritt besteht darin, ein klares geschäftliches Ziel und eine Vision für das API‑Programm einzurichten, die an der übergreifenden Vision des Unternehmens ausgerichtet ist. Eine API ist keine rein technische Lösung und sollte selbst als Produkt oder Geschäftsstrategie behandelt werden – allerdings als Teil der allgemeinen Geschäftsstrategie des Unternehmens.

Somit sollte der nächste Schritt darin bestehen, anhand dieser Vision ein geschäftliches Modell zu erstellen, das Details für Folgendes beschreibt:

Kosten, Ressourcen und Effizienz

• die Systeme, Beziehungen, Aktivitäten und anderen Ressourcen, die das Programm nutzen soll, und die Art, wie das Programm das Unternehmen darin unterstützen soll, diese Ressourcen besser zu nutzen

Wert, Umsatz und Innovation• die Kunden, Märkte und Channels, auf die das Programm abzielt, und die Art und Weise,

auf die technische Innovationen es ermöglichen werden, neuen Umsatz von diesen Zielgruppen zu erwirtschaften

Der Kern dieses geschäftlichen Modells sollte eine Darstellung des Nutzenpotenzials sein, in der der reale, messbare geschäftliche Nutzen klar umrissen ist, den das API‑Programm dem Unternehmen bieten wird.

Teil 3: Koordinieren des API-Designs mit Unternehmenszielen

Teil 4: Entwerfen einer nutzbaren APIUnter rein technischen Aspekten ist es relativ einfach, eine API zu entwerfen. Eine API zu entwerfen, die dem Unternehmen echten Nutzen bringt, kann jedoch wesentlich schwieriger sein. Neben der Funktionalität müssen Unternehmensarchitekten auch die geschäftlichen Ziele und die End User Experience berücksichtigen.

Dies kann besonders dann eine Herausforderung darstellen, wenn ein SOA‑Projekt in den Bereich der APIs erweitert werden soll. Bei einer SOA stehen die Anforderungen des Architekten im Mittelpunkt, und die Anwenderakzeptanz wird vorausgesetzt. Daher betrachten Architekten mit SOA‑Hintergrund API‑Designentscheidungen häufig mit der Annahme, dass Schnittstellen‑ und Anwendungsbenutzer die gleichen Wünsche und Voreingenommenheiten haben wie sie selbst. Dies führt fast immer zu schlechten Designentscheidungen.

Bei APIs sollte der Designschwerpunkt nicht auf der Funktionalität liegen, sondern auf der User Experience. Die wichtigste Frage lautet nicht „Welche Funktionalität muss ich verfügbar machen?“, sondern „Wie werden Entwickler diese Schnittstelle verwenden?“. Wenn Entwickler Ihre API nicht verwenden möchten, ist sie wertlos. Daher muss das Design sich auf die Entwickler konzentrieren und darauf, das geringste mögliche Zugangshindernis für die Entwicklerzielgruppe darzustellen.

Unabhängig davon, ob eine API privat oder für die Allgemeinheit veröffentlicht wird, ist eine gute Developer Experience (DX) unerlässlich für ihren Erfolg. Die DX ist wesentlich schwerer zu quantifizieren als die verfügbar gemachte Funktionalität. Während die DX als die Summe der Interaktionen zwischen dem API‑Anbieter und dem Entwickler definiert werden kann, ist sie eher ein Gefühl als eine Zahl: Wie fühlen sich die Entwickler mit der Schnittstelle?

Derartige Messdaten sind offensichtlich eher nebulös, aber es gibt sicherlich praktische Schritte, die Sie in der realen Welt gehen können, um zu verstehen, wie Ihren Entwicklern wahrscheinlich die unterschiedlichen Ansätze gefallen werden, die für das Design Ihrer API möglich sind. Insbesondere sollten Sie:

• Entwicklerprofile erstellen• Prototypen Ihrer API entwickeln und in der Praxis testen

11

12

EntwicklerprofileSie können nur dann eine nutzbare API erstellen, wenn Sie die Anforderungen und Wünsche Ihrer Entwicklerzielgruppe kennen. Häufig wird angenommen, dass Entwickler, die Clientanwendungen anhand von APIs erstellen, junge selbst ernannte „Hacker“ sind, die von den aktuellen Programmiersprachen und Protokollen besessen sind. In vielen Fällen – vor allem in Szenarien mit privaten APIs – sind Entwickler von Unternehmensservices jedoch älteren Vorgehensweisen treu.

Der Punkt ist, dass jedes API‑Projekt sich an eine bestimmte Entwicklerzielgruppe wenden muss, um erfolgreich zu sein. In einigen Fällen kann dies eine sehr homogene Gruppe mit relativ einheitlichen Anforderungen sein. In anderen müssen Sie möglicherweise viele unterschiedliche Wünsche berücksichtigen. In jedem Fall müssen Sie verstehen, wer Ihre API verwenden soll und wie Sie die Schnittstelle definieren können, um sicherzustellen, dass diese Entwickler Ihre Back End‑Ressourcen schnell und effektiv verwenden können.

Der erste Schritt besteht also darin, ein Persönlichkeitsprofil (oder einen Satz solcher Profile) zu erstellen, um die Art(en) von Entwicklern zu beschreiben, die Zielgruppe Ihrer APIs sind. Hierin sollten Informationen zu Folgendem enthalten sein:

• für wen sie arbeiten (und in welcher Abteilung) und warum sie eine Anwendung entwickeln

• Programmierkenntnisse, technische Einschränkungen und Wünsche hinsichtlich Programmiersprache/Protokoll

• persönliches Temperament und optimaler Arbeitskontext

Erstellung von Prototypen Sobald Sie die Arbeitsziele, technischen Anforderungen und persönlichen Vorlieben Ihrer Entwicklerzielgruppe kennen, können Sie beginnen, eine Schnittstelle zu erstellen, die diese Kriterien erfüllt. Bevor Sie eine Produktions‑API erstellen, die an reale Daten oder Back End‑Systeme gebunden ist, sollten Sie jedoch einen schlanken Prototyp erstellen, der leichter geändert werden kann. Mit diesem Prototyp können Sie die Designannahmen testen, die Sie anhand Ihres Zielprofils zugrunde gelegt haben.

Einer der Vorteile der Erstellung eines schlanken Prototyps anhand von „Wegwerf“‑Daten oder ‑Funktionalität besteht darin, dass Sie nur minimale Security anwenden müssen und das Zugangshindernis für Entwickler minimal ist. Dies ermöglicht es Ihnen, Ihre Entwicklerzielgruppe früh einzubinden. Die Entwickler schreiben dabei einfache Anwendungen, um Ihr API‑Design zu testen und Ihnen Feedback dazu zu geben. Dann können Sie Änderungen an der Schnittstelle vornehmen und sie erneut testen. Nach einigen Iterationen sollten Sie auf dem richtigen Weg sein.

Natürlich bezieht sich nichts hiervon darauf, wie Sie fundamentale, praktische Entscheidungen zum Schnittstellendesign treffen. In Teil 5 beginnen wir, die eigentlichen API‑Designoptionen zu diskutieren.

Teil 4: Entwerfen einer nutzbaren API

Abbildung 4: Nützliche Tools für das API‑Prototyping

Es gibt eine Reihe von Onlinetools, die die Erstellung und das Testing von schlanken API‑Prototypen vereinfachen können.

Beliebte Beispiele sind ...

Ein Designtool, mit dem Sie schnell einen API‑Prototyp erstellen können, ohne Code zu schreiben.

Apiaryapiary.io

RAMLraml.org

SWAGGERswagger.io

API‑Beschreibungssprachen, mit denen Entwickler Ihren Schnittstellenprototyp entdecken und mit seiner Verwendung beginnen können

123

13

Die Auswahl eines API‑Formats ist eine der wichtigsten Entscheidungen, die ein Schnittstellendesigner treffen kann. Entscheidungen dieser Art werden stets von technischen Überlegungen beeinflusst, wie der genauen Art der Back End‑Ressourcen, die verfügbar gemacht werden sollen, oder den Einschränkungen der IT‑Abteilung. Andere Aspekte, wie geschäftliche Ziele des API‑Programms und die Anforderungen und Wünsche der Entwicklerzielgruppe, müssen ebenfalls berücksichtigt werden.

Die zurzeit üblichen API‑Designformate können in die folgenden Kategorien eingeordnet werden:

Teil 5: API-Formate

Web Service (auch bekannt als

Tunneling)

Pragmatic REST (auch bekannt

als URI)

Hypermedia (auch bekannt als

„True REST“)

Ereignisgesteuert (auch bekannt

als IoT)

14

Das Web Service‑Format ist ein transportunabhängiger, betriebsbasierter Ansatz für das API‑Design, bei dem Schnittstellen mit Web Services Description Language (WSDL) beschrieben werden. Es stammt aus dem Bereich der SOA, in dem Web Service‑Schnittstellen verwendet wurden, um heterogene Netzwerke zu integrieren. Daher kann dieses Format eine gute Wahl sein, wenn in Ihrem Programm SOA‑Schnittstellen erweitert werden. Außerdem gibt es für Web Services zahlreiche Tools, sodass Clientanwendungen häufig schnell und leicht erstellt werden können.

Bei der Verwendung dieses Formats gibt es jedoch auch wesentliche Einschränkungen. Erstens kann dieses transportunabhängige Format zwar das Hypertext Transfer Protocol (HTTP) verwenden, ist in diesem Kontext jedoch sehr ineffizient. Daher ist es nicht die beste Wahl, um Ihre Services auf das

offene Web zu erweitern. Außerdem ist es nur dann praktisch nutzbar, wenn Ihre Entwicklerzielgruppe mit SOA‑Standards wie WSDL, Simple Open Access Protocol (SOAP) und Remote Procedure Call (RPC) vertraut ist. Für die meisten Cliententwickler ist die Lernkurve wahrscheinlich steil.

Dies gilt besonders in Szenarien mit offenen APIs; vor allem in solchen, die hauptsächlich für die Mobilität bestimmt sind. Im Allgemeinen arbeiten Anwendungsentwickler nicht gern mit SOAP als Programmiersprache, und die meisten verfügbaren Tools für die Erstellung von Web Service‑Clients unterstützen nicht die Mobilität. Abgesehen von praktischen Überlegungen gibt es ein Wahrnehmungsproblem: Wenn Sie das Web Service‑Format verwenden, kann Ihr Unternehmen wie ein schwerfälliger „Dinosaurier“ wirken. Dies verringert die Akzeptanz bei Entwicklern mobiler Apps.

Das Format Pragmatic Representational State Transfer (REST) ist ein einfacherer, stärker auf das Web ausgerichteter Ansatz für das Design von Integrationsschnittstellen. Dieses Format, das URI statt WSDL verwendet und transportspezifisch ist (da es ausschließlich HTTP unterstützt), ersetzt heute beim Design von APIs im Wesentlichen das Web Service‑Format. Der Begriff „Web‑API“ wird im Allgemeinen austauschbar mit dem Begriff „RESTful‑API“ verwendet, und das Erreichen von „RESTfulness“ wird häufig als wichtiges Ziel jedes Schnittstellendesign‑Projekts angesehen.

In Wirklichkeit erfüllen die meisten heute verwendeten REST‑APIs die REST‑Kriterien nicht vollständig, die in Roy Fieldings bahnbrechender Doktorarbeit aus dem Jahr 2000 definiert sind. Während REST definiert wurde, um die dynamischen, auf Hyperlinks basierenden Interaktionen formal zu beschreiben, auf denen das Web beruht, dienen die meisten Web‑APIs dem Austausch statischer Daten. Daher ist es präziser, dieses Designformat als „Pragmatic REST“ zu bezeichnen.

Es ist leicht zu sehen, warum das Format Pragmatic REST so beliebt geworden ist. Da URI intuitiv ist und Entwickler von Webanwendungen und mobilen Apps überwiegend mit RESTful‑Schnittstellen vertraut sind, ist die Entwicklerakzeptanz und ‑produktivität meist hoch. Außerdem bedeutet die Konzentration auf HTTP, dass Pragmatic REST‑APIs ideal für die Entwicklung aktueller Webanwendungen und mobiler Apps geeignet sind. Zurzeit ist dies wahrscheinlich das Format der Wahl für die meisten Projekte.

Das Format Pragmatic REST ist nicht für jeden Kontext perfekt geeignet, und seine dominante Position wird in Zukunft wahrscheinlich durch alternative Formate streitig gemacht werden. Dieses Format hat deutliche Nachteile: Es ist auf vier Methoden begrenzt, es kann zu ausführlich sein, und das URI‑Design ist nicht standardmäßig. Auch die Tatsache, dass das Internet of Things (IoT) und Big Data sich stark ausbreiten und Onlinenetzwerke verändern, wird wahrscheinlich Herausforderungen für diesen speziell webzentrierten Ansatz bedeuten.

Pragmatic REST

Web Service

Teil 5: API-Formate

151515

Das Designformat Hypermedia‑API ist ein aufgabenbasierter Ansatz, der eine nachhaltigere Alternative zu Pragmatic REST bieten soll. Wie bei Pragmatic REST liegt der Schwerpunkt von Hypermedia‑APIs im Allgemeinen auf den Standards URI, HTTP und RESTful. In gewisser Weise stellt das Hypermedia‑Format jedoch eine genauere Anwendung der RESTful‑Architektur nach Fielding dar. Dies zeigt, warum sich das Web als so hoch skalierbar herausgestellt hat.

Der Hypermedia‑Ansatz als solcher ist sogar noch stärker auf das Web zentriert: Die Hyperlinks und Formen des Web zeigen sich in der Art und Weise, wie eine Hypermedia‑API Links zum Navigieren in Workflows und Vorlageneingaben zum Anfordern von Informationen bereitstellt. So, wie die

RESTful‑Architektur für das Web sich als hoch skalierbar und weiterentwickelbar bewährt hat, kann eine gut entworfene Hypermedia‑API auf Jahre hinaus neue Anwendungen unterstützen.

Während dieser Architekturansatz offensichtlich eine attraktive Option für Unternehmen darstellt, die skalierbare APIs für die langfristige zuverlässige Unterstützung von Webanwendungen und mobilen Apps erstellen möchten, ist er zurzeit noch ein neues Designformat mit deutlich zu wenigen passenden Tools. Dies kann die Akzeptanzraten bei Entwicklern beeinträchtigen und erschwert es den Entwicklern, die die API nutzen, schnell leistungsstarke Clientanwendungen zu erstellen.

Während auf HTTP konzentrierte Formate wie Pragmatic REST und Hypermedia möglicherweise für das Web und für heutige mobile Apps ideal sind, verändert sich die Welt aufgrund von HTML5 und dem IoT: Es entsteht die Möglichkeit dynamischerer Anwendungen, aber es werden auch schlankere Schnittstellen erforderlich. In diesem Kontext zeigt sich das ereignisgesteuerte Format als transportunabhängige Alternative. Es ist ideal geeignet, um Anwendungen in die Lage zu versetzen, WebSocket und andere neue Alternativen zu HTTP zu nutzen.

Dieses Format, dessen Schwerpunkt auf vom Server oder Client initiierten Ereignissen liegt, stellt eine Option mit geringem Aufwand dar, die bessere Performance in Szenarien bieten kann, in denen viele kleine Nachrichten

zwischen dem Back End und der Anwendung übermittelt werden. Daher ist es ideal geeignet für das IoT sowie für eine Reihe von Anwendungsfällen der Mobilität, vor allem Instant Messaging, Videochat, Multi‑Player‑Spiele usw. Außerdem spricht es wahrscheinlich die innovativsten Entwickler an.

Natürlich sind nicht alle Entwickler so besessen davon, an der Spitze der Technologie zu sein, und es gibt zahlreiche Anwendungsfälle, in denen ein herkömmlicher RESTful‑Ansatz besser geeignet ist. HTTP ist weiterhin das Transportprotokoll, das dem Web zugrunde liegt, und es ist nicht besonders gut für Ereignisse geeignet, die vom Client gesendet werden. Außerdem ist die Erstellung von Clientanwendungen mit dem Anforderung‑Antwort‑Modell, auf dem dieses Format basiert, für Entwickler komplexer.

Ereignisgesteuert

Hypermedia

Teil 5: API-Formate

16

Welches Format Sie wählen, hängt von Ihren technischen Einschränkungen, geschäftlichen Zielen und den Wünschen Ihrer Entwickler ab. Vermeiden Sie die Falle, ein „beliebtes“ Format auszuwählen, wenn es nicht für Ihren spezifischen Kontext geeignet ist. Versuchen Sie zugleich, ein Format zu wählen, das sich als langfristig skalierbar und anpassbar erweisen wird, wenn sich Ihre Ressourcen verändern, Ihre Anwenderzielgruppe wächst und das Konzept des Onlinenetworking sich weiterentwickelt.

Unabhängig davon, welches Format Sie wählen, gibt es bestimmte Architekturkomponenten, die Ihre API enthalten sollte. In Teil 6 beschreiben wir diese Komponenten und den organisatorischen Umgang mit ihnen.

Abbildung 5: Architekturformate für das API‑Design

Web Service Pragmatic REST Hypermedia Ereignisgesteuert

SOA‑bezogen Zahlreiche Tools erhältlich

Nicht für Mobilität geeignet

Ideal für Webanwendungen und mobile Apps Den meisten Anwendungsentwicklern vertraut Möglicherweise nicht im Zeitverlauf anpassbar

Stark auf das Web bezogen Skalierbar und weiterentwickelbar Vielen Entwicklern nicht vertraut

Geeignet für loT und Geräte Schlank und dynamisch

Nicht für Standardszenarien geeignet

Teil 5: API-Formate

17

Abbildung 6: Ebenen der Architektur

Die oben beschriebenen Designformate für die Architektur sollen ein Modell für den Entwurf des Architekturframeworks bereitstellen, das die einzigartige Funktionalität Ihrer API‑Implementierung unterstützt. Bestimmte Anwendungsfälle erfordern die Implementierung bestimmter Designformate. Es ist jedoch auch wichtig zu beachten, dass eine Reihe von Komponenten unabhängig vom Anwendungsfall in jede API‑Architektur eingeschlossen werden sollte.

Diese gemeinsamen Architekturkomponenten sollten nicht in die Implementierung einer einzelnen API integriert werden. Stattdessen sollten sie in einer API‑Kerninfrastruktur bereitgestellt werden, die sich zwischen den APIs der Organisation und den Clientanwendungen befindet, die diese APIs nutzen. Wenn Sie diese Komponenten separat implementieren, können Sie schneller und leichter zusätzliche APIs entwerfen, eine Reihe von APIs gemeinsam aktualisieren und die reibungslose Ausführung von APIs, Back End‑Systemen und Clientanwendungen sicherstellen.

Um maximale Effektivität zu erreichen, sollten diese Komponenten als Ebenen entworfen werden, sodass der gesamte Datenverkehr die rechts genannten Ebenen in der angegebenen Reihenfolge durchlaufen muss.

Teil 6: API-Architektur

Securityebene

Caching-Ebene

Darstellungsebene

Orchestrierungsebene

Clientanwen‑dungen

End User

Back End‑Systeme

API‑Implementierung

Die Security-EbeneAPIs eröffnen nicht nur ganz neue Geschäftschancen, sondern können das Unternehmen auch für schwerwiegende neue Securitybedrohungen anfällig machen, indem sie sensible Back End‑Systeme und Daten für Außenstehende verfügbar machen. APIs sind anfällig für viele der Securitybedrohungen im Web sowie für eine Reihe neuer API‑spezifischer Bedrohungen. Daher ist es unerlässlich, eine strenge, API‑spezifische Security in der API‑Architektur bereitzustellen.

Diese Notwendigkeit einer strengen Security kann mit einem grundlegenden Ziel des API‑Designs in Konflikt stehen: Eine gut entworfene API erleichtert Entwicklern die Erstellung von Anwendungen, die nahtlosen Zugriff auf Unternehmensressourcen bieten. Eine strenge Security beeinträchtigt oft diesen mühelosen Zugriff. Indem Sie die Security in einer zentralisierten API‑Architektur (statt in der API‑Implementierung) bereitstellen, können Sie diese Auswirkungen verringern. Ebenfalls hilfreich ist die Verwendung flexibler Access Management‑Technologien wie OAuth und OpenID Connect.

Die Caching-EbeneDie Effizienz der Schnittstelle ist sehr wichtig, um die reibungslose Experience für Entwickler und End User bereitzustellen, die notwendig ist, um Ihre Ziele hinsichtlich der Akzeptanz und Aufrechterhaltung Ihres API‑Programms zu erreichen. Eine Möglichkeit, die Effizienz von APIs zu maximieren, besteht darin, eine Caching‑Ebene zwischen externem Zugriff und API‑Gateway zu platzieren. Diese Ebene soll es ermöglichen, dass Antworten auf häufige Anforderungen aus dem Cache bereitgestellt werden. So wird der Druck reduziert, dem die tatsächlichen API‑Implementierungen und Back End‑Ressourcen ausgesetzt sind.

Die DarstellungsebeneOffensichtlich sollte die Darstellung Ihrer API so entwicklerfreundlich sein wie möglich. Indem Sie dieses Element separat implementieren, können Sie sich darauf konzentrieren, zentral einen komfortablen Zugang zu Ihren APIs zu erstellen, ohne dass Auswirkungen auf die eigentlichen APIs oder Back End‑Ressourcen entstehen. Dies macht es erheblich leichter, komplexe Back End‑Systeme als Schnittstellen für Webanwendungen und mobile Apps darzustellen, die Entwickler schnell verstehen und nutzen können, um leistungsstarke, anwenderfreundliche Anwendungen zu erstellen.

Die OrchestrierungsebeneWährend einige Anwendungen möglicherweise Nutzen bieten können, indem sie über eine einzelne API auf eine einzelne Ressource zugreifen, wachsen die Möglichkeiten exponentiell, wenn Sie Daten aus mehreren APIs (einschließlich APIs von anderen Unternehmen) und aus Back End‑Ressourcen kombinieren. Indem Sie eine Orchestrierungsebene zusammen mit den eigentlichen Schnittstellen bereitstellen, können Sie solche Kombinationen ermöglichen sowie den Prozess für die Zusammenstellung neuer Implementierungen aus mehreren Back End‑Ressourcen vereinfachen.

Die effizienteste Möglichkeit, eine zentralisierte API‑Architektur zu erstellen, besteht in der Bereitstellung einer Lösung für das API Management. In Teil 7 umreißen wir wichtige Komponenten des API Management.

18

Teil 6: API-Architektur

Durch die Erstellung einer Infrastruktur, in der häufige Architekturkomponenten sicherer, entwicklerzentrierter APIs zentralisiert werden, kann der Implementierungsprozess für APIs wesentlich vereinfacht werden, die Ihrem Unternehmen echten Zusatznutzen bringen. Eine solche Infrastruktur intern zu erstellen, kann jedoch eine wesentliche Herausforderung bedeuten. Glücklicherweise bietet eine Reihe von Unternehmenssoftware‑Anbietern jetzt Lösungen für das API Management, mit denen diese wichtige Infrastruktur nicht mehr intern entwickelt werden muss.

Wie der Name schon sagt, umfassen Lösungen für das API Management auch Funktionalität für die langfristige Verwaltung und Optimierung der Performance von APIs. Die leistungsstärksten Lösungen umfassen auch Funktionen für die Erstellung einer webgestützten Schnittstelle, über die Entwickler APIs entdecken, kennenlernen und auf sie zugreifen können. Dies ist ein unerlässlicher Teil der Bereitstellung einer entwicklerzentrierten API, der nicht in die eigentliche Implementierung integriert werden kann.

Teil 7: API Management

19

Beachten Sie, dass das API Management nicht einfach eine technische Anforderung ist. Es spielt stets eine Rolle für den geschäftlichen Erfolg jedes API‑Unternehmensprogramms. Ein geeignetes Management der Zusammenstellung, Performance und Security von Unternehmens‑APIs ist unerlässlich, um sicherzustellen, dass das Unternehmen eine hohe Rendite für seine Investition in ein API‑Programm erzielt. Ebenso müssen Sie Entwickler unbedingt aktiv einbinden und verwalten, um sicherzustellen, dass sie Anwendungen entwickeln, die geschäftlichen Nutzen bringen.

In den meisten Unternehmen wird sich herausstellen, dass eine API Management‑Infrastruktur unverzichtbar ist, um APIs zu entwerfen, bereitzustellen und zu pflegen, mit denen Entwickler wirklich leistungsstarke neue Anwendungen erstellen.

20

Abbildung 7: Komponenten des API Management

Anwendungsentwickler

ClientanwendungEnd User

API‑Verantwortlicher

API‑Implementierung

Entwicklerportal

API-Gateway

Teil 7: API Management

Entdecken Sie die Grundlagen des API Management mit dem eBook „Die 5 Säulen des API Management“

API‑Architekt

Back End‑Systeme

Komponenten des API ManagementEine API Management‑Lösung für ein Unternehmen umfasst zwei wichtige Komponenten:

• API‑Gateway – bietet die Security‑, Gateway‑ und Orchestrierungsfunktionalität, die notwendig sind, um eine API‑Kernarchitektur bereitzustellen• Entwicklerportal – bietet eine anpassbare Benutzeroberfläche, über die Entwickler auf die APIs sowie auf Dokumentation, Communityforen und

andere nützliche Inhalte zugreifen

2121

Unter dem Aspekt der Architektur stellen APIs eine Erweiterung der SOA dar. So, wie die SOA Schnittstellen erstellte, um Legacy Systems zur Wiederverwendung in neuen Services verfügbar zu machen, die organisatorische Grenzen überqueren konnten, werden APIs verwendet, um das Back End des Unternehmens für Entwickler verfügbar zu machen, die Anwendungen für Mobile Devices und für das öffentliche Web erstellen. Dies ist eine wesentliche Erweiterung, und es ist wahrscheinlich, dass die Designanforderungen für eine Web‑API sich stark von denen für einen Web Service der SOA unterscheiden werden.

Während SOA‑Programme im Allgemeinen durch die Notwendigkeit motiviert sind, IT‑Kosten einzusparen, konzentrieren sich API‑Programme auf die Erschließung neuer Umsatzquellen. Eine Web‑API verbindet eine Reihe vorhandener Unternehmensassets, um Arten der Wertschöpfung zu erreichen, die zuvor undenkbar waren. Ein gutes API‑Design konzentriert sich stets auf Unternehmensergebnisse. Daher müssen Design‑ und Architekturpraktiken für APIs von Grund auf mit der geschäftlichen Strategie des Unternehmens koordiniert werden.

API‑Verantwortliche und ‑Architekten müssen miteinander kommunizieren, um sicherzustellen, dass sie sich darüber einig sind, was ihre wesentlichen Ziele sind, wie sie sie erreichen möchten und wie sie ihren Erfolg messen werden. Um sicherzustellen, dass die Kommunikation effektiv ist, sollte ein API‑Vorreiter, der die Kluft zwischen geschäftlichen und technischen Rollen überbrücken kann, die Anforderungen von geschäftlichen Führungskräften, API‑Verantwortlichen, Anwendungsentwicklern und Unternehmensarchitekten untersuchen, um passende Ziele, Aufgaben und Messdaten zu verhandeln.

In der Praxis muss beim Design einer API, die geschäftlichen Erfolg bringen soll, im Allgemeinen eine Schnittstelle erstellt werden, die Entwickler gern verwenden. Bevor Sie etwas erstellen, müssen Sie daher unbedingt Ihre Entwicklerzielgruppe systematisch erforschen, um zu verstehen, wer diese Entwickler sind und was sie sich von einer API wünschen. Es kann außerdem nützlich sein, alle Annahmen zu den Wünschen der Entwickler zu testen, indem Sie schlanke API‑Prototypen anbieten.

Schlussbemerkungen

Sobald Sie bereit sind, Ihre tatsächliche API‑Implementierung zu entwerfen, müssen Sie das Designformat auswählen, das am besten zu Ihrem Projekt passt. Web Service‑APIs passen zu internen Programmen, deren Zielgruppe Entwickler mit SOA‑Erfahrung sind. Pragmatic REST‑APIs sind eher für offene API‑Projekte geeignet, deren Schwerpunkt auf Mobile Devices und dem Web liegt. Das Hypermedia‑Format und das ereignisgesteuerte Format stellen sich als Ansätze heraus, die sich möglicherweise in der Zukunft, in der Mobilität und das IoT eine wichtige Rolle spielen werden, als nachhaltiger herausstellen werden.

Unabhängig vom Format gibt es bestimmte Architekturelemente, die jede API einschließen muss, nämlich Security, Caching, Darstellung und Orchestrierung. Um maximale Effizienz und Verwaltbarkeit zu erreichen, dürfen diese Elemente nicht in die einzelnen API‑Implementierungen integriert werden. Stattdessen sollten alle APIs eine zentrale, in Ebenen aufgebaute Architektur nutzen.

Die effizienteste und effektivste Methode, um eine zentrale API‑Architektur bereitzustellen – und sicherzustellen, dass das API‑Programm langfristig erfolgreich bleibt – ist die Einführung einer Lösung für das API Management. Es ist eine Reihe unterschiedlicher Lösungen auf dem Markt, aber die meisten haben zwei Komponenten gemeinsam:

• ein API‑Gateway, das Securityfunktionen und weitere wichtige Infrastruktur bereitstellt

• ein Entwicklerportal, das den Prozess der Einbindung und Unterstützung von Entwicklern erleichtert

Bei heutigen API‑Unternehmensprojekten geht es um viel – riesige Geschäftschancen, wesentliche Securityrisiken und vieles mehr. Es ist unerlässlich, dass Sie sich gut vorbereiten, bevor Sie mit der Erstellung einer API beginnen: Koordinieren Sie Designziele mit Unternehmenszielen, ermitteln Sie die Wünsche Ihrer Entwicklerzielgruppe, wählen Sie ein geeignetes Implementierungsformat und stellen Sie eine Infrastruktur für das API Management bereit. Dann sind Sie bereit, eine wirklich wertvolle API zu erstellen.

22

Abbildung 8: Voraussetzungen für gutes Design

Koordination technischer und geschäftlicher Ziele

Ermittlung der Wünsche der Entwickler

Wahl eines API‑Designformats

Bereitstellung der API‑Infrastruktur

Schlussbemerkungen

€

Nur mit CA API Management können Unternehmen Systeme integrieren, die Anwendungsentwicklung vereinfachen und Daten als Grundlage für Umsätze verwenden, wobei sie zugleich das Level an API‑Security und ‑Schutz erreichen, das Unternehmen

heute benötigen. Weitere Informationen zu CA API Management finden Sie unter ca.com/de/api.

Copyright © 2015 CA Technologies. Alle Rechte vorbehalten. Alle Markenzeichen, Markennamen, Dienstleistungsmarken und Logos, auf die hier verwiesen wird, sind Eigentum der jeweiligen Unternehmen. Dieses Dokument dient ausschließlich zu Informationszwecken. CA übernimmt für die Genauigkeit oder Vollständigkeit der Informationen keine Haftung. Soweit nach anwendbarem Recht erlaubt, stellt CA dieses Dokument im vorliegenden Zustand ohne jegliche Gewährleistung zur Verfügung; dazu gehören insbesondere stillschweigende Gewährleistungen der Markttauglichkeit, der Eignung für einen bestimmten Zweck und der Nichtverletzung von Rechten Dritter. In keinem Fall haftet CA für Verluste oder unmittelbare oder mittelbare Schäden, die aus der Verwendung dieses Dokuments entstehen; dazu gehören insbesondere entgangene Gewinne, Betriebsunterbrechung, Verlust von Goodwill oder Datenverlust, selbst wenn CA über die Möglichkeit solcher Schäden informiert wurde.

CS200‑131275

CA Technologies (NASDAQ: CA) entwickelt Software, die Unternehmen bei der Umstellung auf die Application Economy unterstützt. Software steht in allen Branchen und in allen Unternehmen im Mittelpunkt. Ob Planung, Entwicklung, Management oder Security – CA Technologies arbeitet weltweit mit Unternehmen zusammen, um die Art, wie wir leben, Transaktionen abwickeln und kommunizieren, in mobilen, privaten und öffentlichen Cloud‑Umgebungen oder in verteilten Systemen und Mainframe‑Umgebungen neu zu gestalten. Weitere Informationen finden Sie unter ca.com/de.

Über CA API Management Mit über 300 API Management‑Kunden in so unterschiedlichen Branchen wie Kommunikation und Finanzdienstleistungen sowie im öffentlichem Sektor und im Einzelhandel bietet CA Technologies branchenführende Technologien und Know‑how, mit denen Unternehmen APIs zur Wertschöpfung nutzen können. CA Technologies bietet eine vollständige Lösung für das API Management. Diese umfasst ein API‑Gateway mit vollständiger Funktionalität und militärtauglichen Securityfunktionen sowie ein Entwicklerportal, das als lokale Version und über SaaS angeboten wird. Weitere Informationen zu CA API Management finden Sie unter ca.com/de/api.

API Academy Services für API‑Strategie, ‑Architektur und ‑DesignDas API Academy‑Team besteht aus Branchenexperten, die von CA Technologies zusammengebracht wurden, um kostenlose Ressourcen für die Community zu entwickeln und Beratungsdienstleistungen für Unternehmen bereitzustellen, die ihre API‑Programme wesentlich verbessern möchten. Um zu erfahren, wie die API Academy Ihrem Unternehmen mit API‑Strategie, ‑Architektur und ‑Design helfen kann, besuchen Sie apiacademy.com.