Es muss noch viel Arbeit geleistet werden, um die API zu implementieren. Übermäßige Planung kann Energieverschwendung sein und ihr Mangel führt zu katastrophalen Folgen. In diesem Buch erhalten Sie Lösungen, mit denen Sie die erforderlichen Ressourcen zuweisen und in der optimalen Zeit das erforderliche Effizienzniveau erreichen können. Wie kann man Flexibilität und Leistung in Einklang bringen und gleichzeitig Zuverlässigkeit und einfache Konfiguration gewährleisten? Vier Experten der API Academy erklären Softwareentwicklern, Produkt- und Projektmanagern, wie sie den Wert ihrer APIs maximieren können, indem sie Schnittstellen als Produkte mit kontinuierlicher Lebensdauer verwalten.
Das Material in dem Buch basiert auf unserem kollektiven Wissen (Mehdi Mejuy, Eric Wilde, Ronnie Mitra, Mike Amundsen) über viele Jahre der Erstellung, Entwicklung und Verbesserung der API - sowohl unserer eigenen als auch anderer. Es beschreibt alle unsere Erfahrungen. Wir haben zwei Schlüsselfaktoren für eine effektive API-Entwicklung identifiziert: die Notwendigkeit eines produktorientierten Ansatzes und die Bildung des richtigen Teams. Wir haben auch drei wichtige Faktoren für das Management dieser Arbeit identifiziert: Führung, Produktentwicklung und API-Systementwicklung.
Diese fünf Elemente bilden die Grundlage für die Erstellung eines erfolgreichen API-Verwaltungsprogramms. Wir führen den Leser in all diese Themen ein und geben Anleitungen, wie Sie sie in den Kontext Ihrer Organisation integrieren können.
Auszug. API-Systeme
Mit der wachsenden Funktionalität der API wird es immer wichtiger, Entwicklungsprogramme so zu verwalten, dass der Nutzen und der Wert des gesamten Satzes von Organisations-APIs maximal wachsen. Sie müssen sich an dieses Gleichgewicht erinnern, da der beste (oder relativ gute) Weg, einen einzelnen Dienst mithilfe der API bereitzustellen, möglicherweise überhaupt nicht so nützlich ist, wenn Sie ihn unter dem Gesichtspunkt der Benutzerfreundlichkeit dieses Dienstes als Teil eines gemeinsamen Systems betrachten.
Moderne API-Systeme wachsen ständig in Bezug auf die Gesamtzahl der APIs sowie die Anzahl der von neuen Diensten verwendeten APIs. Angesichts dieser Zunahme der gegenseitigen Abhängigkeiten verstehen wir, dass es nützlich wäre, wenn die Entwickler neuer Dienste nicht völlig unterschiedliche API-Designs verstehen und anwenden müssten. Die Unterschiede können dramatisch sein - beispielsweise, ob die API einen REST- oder einen ereignisorientierten Stil verwendet (siehe Abschnitt Design im Abschnitt Einführung in die Säulen in Kapitel 4) -, aber selbst wenn die Stile übereinstimmen, können Unterschiede wie die Verwendung des JSON-Formats erkannt werden oder XML.
Aus Sicht eines API-Benutzers wäre es auch nützlich, eine gemeinsame Terminologie zu haben. Wenn Sie beispielsweise mehrere APIs verwenden, die Benutzerdaten in beliebiger Form bereitstellen, ist es einfacher, wenn alle ein Hauptbenutzermodell haben (auch wenn es geringfügig anders dargestellt wird, es ist jedoch nützlich, ein gemeinsames Modell für verschiedene Dienste zu haben). .
Die Vorstellung von den Vorteilen der Normung zeigt deutlich, dass je mehr es ist, desto besser. Bis zu einem gewissen Grad ist dies der Fall, aber gleichzeitig ist bekannt, dass Standardisierung Zeit und Ressourcen erfordert. In der Regel handelt es sich nicht um das "einzig wahre und beste Modell", sondern lediglich um ein Modell, mit dem sich jeder irgendwie abfinden kann Daher hat diese Investition im Allgemeinen sowohl Risiken als auch Vorteile.
Möglicherweise ist die Verwendung eines eindeutigen Formats für jede API nicht die beste Lösung. Es ist sinnvoller, aus vorhandenen Formaten auszuwählen, z. B. JSON oder XML. In diesem Fall überwiegen die Vorteile der Anwendung bestehender Standards die wahrscheinlichen Vorteile eindeutiger Formate. Es kann jedoch sehr teuer sein, einige Elemente verschiedener Dienste zu standardisieren, beispielsweise das bereits erwähnte Benutzermodell. In diesem Fall ist es logisch, nicht zu solchen ungerechtfertigten Ausgaben zu gehen, um das einzig wahre Benutzermodell zu finden und einfach beim Domänenmodell anzuhalten.
Im Allgemeinen möchten wir, idealerweise für jeden Service, das Rad nicht neu erfinden, wenn es nicht benötigt wird, sondern diejenigen Designelemente wiederverwenden, die die Kosten für Ressourcen für die Erstellung eines Designs, dessen Verständnis und Implementierung senken. Wenn wir ein so ideales Maß an Neuanwendung erreichen oder zumindest näher daran heranrücken können, können sich die Serviceentwickler auf die Aspekte des Designs konzentrieren, auf die sie sich konzentrieren müssen, ohne von bereits gelösten Problemen abgelenkt zu werden.
Wir sehen immer mehr Organisationen, die genau das tun. Das Wichtigste dabei ist jedoch, zu verstehen und sicherzustellen, dass die Handbücher für Designer ständig aktualisiert werden: Neue Methoden werden evaluiert und genehmigt, alte Methoden werden aus dem Verkehr gezogen, und die Hauptantriebskraft für diese Änderungen sind die sich ständig weiterentwickelnden API-Methoden in der Organisation.
Es ist wichtig zu verstehen, dass das API-System eine mobile und sich ständig ändernde Umgebung ist. Damit es weiterhin funktioniert, muss die Architektur denselben Weg der kontinuierlichen Entwicklung einschlagen. Dann wird es wie ein sehr großes System, zum Beispiel das Internet, das einerseits ständig funktioniert und andererseits sich ständig ändert und ständig neue Standards und Technologien darin auftauchen.
Archäologie-API
Obwohl wir jetzt eine große Anzahl von Organisationen sehen, die gerade erst anfangen, Programme mit APIs zu erstellen, ist es wichtig zu bedenken, dass es in jeder Organisation, die Informationstechnologie verwendet, mit ziemlicher Sicherheit einige APIs gibt, die seit langer Zeit verwendet werden.
Basierend auf der Definition ist eine API eine beliebige Schnittstelle, über die zwei Softwarekomponenten interagieren können. Wenn Sie die Definition auf ein modernes Verständnis der Netzwerk-API eingrenzen, ist dies eine beliebige Schnittstelle, über die zwei Softwarekomponenten über das Netzwerk interagieren können.
In vielen Organisationen werden solche Schnittstellen nicht als APIs bezeichnet und können nicht wiederverwendet werden (erinnern Sie sich an die Geschichte über die berühmte API-Charta von Jeff Bezos, die wir im Unterabschnitt Bezos-Charta im Abschnitt Design Thinking in Kapitel 3 erzählt haben). Meistens existieren diese Schnittstellen jedoch, selbst wenn sie nur für eine einmalige Verwendung erstellt und für die Integration verwendet wurden (was eine der wichtigsten nützlichen Eigenschaften der API untergräbt - die Möglichkeit der Wiederverwendung).
Das Finden und Anwenden solcher Proto-APIs kann nützlich sein, da sie zeigen, wo der Integrationsbedarf aufgetreten ist (auch wenn sie mit Methoden erstellt wurden, die die Ziele der API nicht erfüllten). Nicht alle dieser Proto-APIs sollten durch herkömmliche APIs ersetzt werden. Wenn Sie jedoch nur den Verlauf verstehen, können Sie sich ein Bild davon machen, wie der Integrationsbedarf festgestellt wurde, was in diesem Bereich getan wurde und wo der Bedarf an zusätzlicher Integration auftreten kann.
PROTO API
Die Notwendigkeit für das Zusammenspiel von Komponenten besteht in allen komplexen Systemen, die aus getrennten Teilen bestehen. Eine API ist eine Möglichkeit, dies zu tun, aber es gibt viele andere. Aus Sicht der API kann jeder Mechanismus, der für die Interaktion von Komponenten verwendet wird, die keine API sind, als Proto-API betrachtet werden. In einem idealen System werden unter Verwendung der API alle Komponenteninteraktionen ausnahmslos ausgeführt. Wenn Sie sich an dieses ideale Bild erinnern, wird jede Interaktion ohne die Hilfe der API zu einem Kandidaten für eine Modernisierung, die durch eine API ersetzt wird. Daher kann jeder Mechanismus für die Interaktion von Komponenten ohne die Hilfe einer API als Proto-API betrachtet werden.
Im Allgemeinen kann Ihnen die API-Archäologie helfen, das API-System besser zu verstehen, auch wenn es jetzt hauptsächlich aus Proto-APIs besteht. Es bietet einen Ausgangspunkt für das Verständnis des in der Vergangenheit aufgetretenen Integrationsbedarfs und für welche API-Investitionen Sie das problematische Netzwerk vieler Benutzerintegrationen am besten entschlüsseln können. Mit der Erfahrung und im Laufe der Zeit wird es immer einfacher, Integrationen, die vor dem Aufkommen der API erstellt wurden, durch moderne Modelle zu ersetzen.
API-Management in großem Maßstab
Ein umfangreiches API-Management ist der Spagat zwischen der Einführung eines gemeinsamen Entwurfs auf Systemebene und der Maximierung der Entscheidungsfreiheit auf der Ebene der einzelnen APIs. Die Wahl zwischen zentraler Integration für Konsistenz und Optimierung und Dezentralisierung für Flexibilität und Entwicklung ist ein häufiges Problem in einem komplexen System.
- Die zentralisierte Integration hat uns die typische Unternehmens-IT-Architektur der Vergangenheit gebracht. Die Hauptantriebskraft war die Standardisierung der Ausführung von Funktionen, um sie optimal und mit minimalen Kosten bereitzustellen. Ein hoher Integrationsgrad vereinfacht die Optimierung erheblich, beeinträchtigt jedoch gleichzeitig die Fähigkeit, Änderungen vorzunehmen und das endgültige System zu entwickeln.
- Dezentralisierung ist das Gegenteil. Das zugänglichste und umfangreichste Beispiel dafür ist das Internet. Die Hauptantriebskraft hierbei ist die Standardisierung des Zugriffs auf Funktionen, damit Sie diese auf viele verschiedene Arten bereitstellen können, die sich ständig weiterentwickeln. Gleichzeitig bleiben die Funktionen verfügbar, da der Zugriff auf allgemeinen Vereinbarungen über das Zusammenspiel von Funktionen beruht. Das Hauptziel der Dezentralisierung besteht darin, die Kohärenz zu schwächen ( http://bit.ly/2FpcUpf ), dh Änderungen in einzelnen Teilen des Gesamtsystems zu erleichtern, ohne dass andere Teile geändert werden müssen.
DEZENTRALISIERUNG UND AUSFÜHRUNG
Wenn wir aus den unvollständig erfüllten Versprechungen der Zeit einer serviceorientierten Architektur auf SOAP-Basis etwas gelernt haben, ist eine sorgfältig verwaltete Ausführung ein Schlüsselaspekt bei der Implementierung serviceorientierter Perspektiven. SOAP erfüllte das Versprechen, Zugang zu Funktionen zu gewähren, erfüllte jedoch nicht die ebenso wichtige Aufgabe, die Ausführung von Funktionen ordnungsgemäß zu verwalten. Obwohl SOAP nützlich war (Funktionen, die zuvor nicht verfügbar waren, wurden als Dienste angezeigt), entsprach es nicht den Anforderungen einer flexibleren und sich weiterentwickelnden Umgebung.
Die Komplexität der Verwaltung des API-Systems besteht darin, sich an dieses Problem zu erinnern und die Falle zu vermeiden, in die SOAP geraten ist. SOAP sagte, dass nur die Verfügbarkeit von Diensten wichtig ist. Dies war ein wichtiger erster Schritt, der es jedoch nicht ermöglichte, die schwache Kohärenz der Funktionen zu bewältigen. Die APIs und, wenn Sie sich besonders auf Implementierungs- und Bereitstellungstechniken konzentrieren, Microservices ermöglichen es uns, zu überdenken, was für große Service-Systeme wichtig ist und wie Systeme erstellt werden, die nicht in die SOAP-Falle fallen.
Plattformprinzip
Viele sprechen über Plattformen, diskutieren APIs und Hauptgeschäftsziele. Sie können jedoch ganz andere Dinge bedeuten. Es ist wichtig, sich daran zu erinnern: Wenn es auf Unternehmensebene eine gute Idee ist, etwas als Plattform zu schaffen, bedeutet dies nicht, dass es auf technischer Ebene so entwickelt werden sollte.
Auf geschäftlicher Ebene bietet die Plattform etwas, auf dem etwas aufgebaut werden kann, und wir können nicht tiefer gehen als diese eher vage Formulierung. Oft wird die Attraktivität des Konzepts der „Plattform“ von zwei Hauptfaktoren beeinflusst.
- Was ist die Plattformabdeckung? Das heißt, wie viele Benutzer können erreicht werden, indem etwas auf dieser Plattform erstellt wird? Dies wird normalerweise durch die Anzahl der Benutzer oder Abonnenten bestimmt. Oft ist dies der wichtigste Parameter, berechnet anhand der Gesamtzahl oder unter Verwendung qualitativer Faktoren, die die richtigen Benutzer bestimmen, die über diese Plattform abgedeckt werden können.
- Welche Funktionen hat diese Plattform? Wenn Sie etwas darauf erstellen, wie hilft es Ihnen oder begrenzt es Sie in Bezug auf das Einkommen? Und ist es auch einfach, die Plattform zu ändern, um neue Funktionen hinzuzufügen, idealerweise ohne die Benutzer zu schädigen?
Diese Parameter sind für das Geschäft sehr wichtig, aber es gibt einen Faktor, der oft vergessen wird: Plattformen zwingen Benutzer immer dazu, bestimmte Einschränkungen einzuhalten, aber sie tun dies auf unterschiedliche Weise. Hier sind einige Beispiele.
- Webanwendungen können von jedem und jedem verwendet werden, der grundlegende Netzwerkstandards erfüllt. Im einfachsten Fall handelt es sich um einen modernen Browser mit Skriptunterstützung. Jeder kann sie erstellen und den Zugang zu ihnen öffnen, und jeder kann sie verwenden. Es gibt kein zentrales Element, das den Betrieb der Webplattform steuert.
- Anwendungen im App Store von Apple sehen ähnlich aus wie Webanwendungen, werden jedoch auf völlig unterschiedliche Weise bereitgestellt und verwendet. Sie können nur aus dem App Store heruntergeladen werden, sodass Apple das ausschließliche Recht hat, zu entscheiden, welche Benutzer installiert werden dürfen. Darüber hinaus können sie nur auf iOS-Geräten ausgeführt werden, dh Apple hat das Monopol auf den Verkauf von Geräten, die diese Anwendungen verwenden können. Anwendungen im App Store werden speziell für die iOS-Umgebung erstellt, dh Investitionen in ihre Erstellung sind nur durch diese Plattform begrenzt. Um die Anwendung auf einer anderen Plattform, einschließlich dem Internet, verwenden zu können, muss sie in einer anderen Entwicklungsumgebung und sogar in einer anderen Programmiersprache reproduziert werden. Dies bedeutet: Die Clientseite der Anwendung muss von Grund auf neu erstellt werden.
Sie können diese Vorlage sowohl auf API-Systeme als auch auf die Idee anwenden, eine API-Plattform für Anwendungen zu erstellen.
Manchmal bezieht sich die API-Plattform auf eine bestimmte Umgebung, die den Zugriff auf die API ermöglicht. Bald ähnelt es leicht dem traditionellen Enterprise Service Bus, bei dem eine ähnliche Plattform die Infrastruktur bereitstellen sollte, und die APIs werden zugänglich, da sie sie verwenden können.
In anderen Fällen, wenn es um die API-Plattform geht, bedeutet dies eine Reihe gemeinsamer Prinzipien, die von Diensten verwendet und bereitgestellt werden. Wenn der Dienst Teil der Plattform wird, hat dies in diesem Fall nichts damit zu tun, wo und wie der Zugriff darauf geöffnet wird. Wenn Dienste dieselben Prinzipien, Protokolle und Vorlagen einhalten, stellen sie APIs auf dieser Plattform bereit und werden so Teil des API-Systems.
Der zweite Plattformtyp ist abstrakter, verfügt jedoch gleichzeitig über mehr Funktionen. Durch die Trennung, welche Funktionen ausgeführt werden und wie sie ausgeführt werden, wird der Beitrag der Benutzer zur Plattform erleichtert. Es eröffnet auch viele Möglichkeiten für Innovationen, sodass Anwendungen mit Implementierungsmethoden experimentieren können, ohne ihre Fähigkeit zu beeinträchtigen, zum API-System beizutragen.
Nehmen Sie noch einmal das Internet als Beispiel. Wenn Sie nur aus der Sicht der API schauen, kann sich im Laufe der Zeit viel ändern. Beispielsweise ist ein Content Delivery Network (CDN) nicht in das Internet selbst integriert. Möglich wurde dies durch die Komplexität des Internetinhalts und die Flexibilität des Browsers, mit dem Sie Webseiten auf der Grundlage mehrerer Quellen erstellen können, die möglicherweise von verschiedenen Orten stammen. Man könnte argumentieren, dass das Potenzial zur Erstellung eines CDN bereits in den Prinzipien und Protokollen der ersten Webseiten vorhanden war, aber die CDN-Vorlage erschien erst, als sie entstand.
Diese Fähigkeit zur Anpassung an neue Aufgaben ist in API-Systemen erforderlich. Wir entwerfen ein System, das auf offenen und erweiterbaren Prinzipien und Protokollen basiert, aber wir können und wollen es bei Bedarf ändern. Wir erstellen auch Support-Vorlagen, mit denen Anwendungen Probleme effizienter lösen können, und wir möchten diese Vorlagen im Laufe der Zeit entwickeln.
Prinzipien, Protokolle und Vorlagen
Die Hauptschlussfolgerung aus dem vorherigen Abschnitt: Die Plattform sollte keine bestimmte Art und Weise erfordern, etwas zu tun (beantworten Sie die Frage „Wie?“) Oder einen bestimmten Ort (Antwort auf die Frage „Wo?“). Für die kontinuierliche Weiterentwicklung der Architektur wird eine gute Plattform geschaffen, dh die Architektur der Plattform (und nicht nur die Architektur des Produkts) entwickelt sich ständig weiter und nicht alle werden gleichzeitig entwickelt, so dass sie während ihrer gesamten Existenz unverändert bleibt.
KONTINUIERLICHE ARCHITEKTURENTWICKLUNG
Die kontinuierliche Architekturentwicklung ist eine Methode zur kontinuierlichen Entwicklung der Grundlagen der Produktarchitektur. Einzelne Produkte werden unter Verwendung vorhandener Architektur-Frameworks erstellt, und Berichte über die Anwendung dieser Frameworks können die Produktarchitektur verbessern und effizienter machen.
Eine flexible Entwicklungsmethode und DevOps zielen darauf ab, die Entwicklung einzelner Produkte zu verbessern. Sie sprechen nicht darüber, wie die Grundlagen dieses Prozesses verbessert werden können, damit eine effizientere Systemarchitektur für die Produktarchitektur nützlich ist. Kontinuierliche Entwicklung erfolgt, wenn einzelne Produkte in der Arbeitsumgebung eines vorhandenen Systems erstellt werden. Das System erleichtert die Erstellung neuer Produkte und hilft dem System, Verbesserungsmöglichkeiten zu finden, wodurch eine Rückkopplungsschleife entsteht.
Die kontinuierliche Architekturentwicklung konzentriert sich auf die Entwicklung eines Frameworks, das vorhandene Produkte nicht schädigt und die Erstellung von Produktkombinationen ermöglicht. , , .
, , . -. , . 30 , , , . ? , .
, , . , , , , . — , , , . — . , , , , , IT-, . .
- — , . — , (uniform resource identifier, URI), URI . , ( ) HTTP ( - , HTTPS), , . API, .
- , . (Hypertext Transfer Protocol (HTTP)), (FTP) , WebSockets WebRTC. , , HTTP/2.
- — . , , , . — Oauth, HTTP, — . — . , Oauth, , CDN. , , , , . — , .
, . , , . , -, .
, . . , - , . , , . , , , .
API . , , , , , . API — , , .
API
API . , , . , «» API, , API, .
API .
- API (, / ) . , API RPC — , API REST .
- API . , API HTTP HTTP.
- API . , 200 HTTP ( http://webconcepts.info/concepts/http-header/ ), . API , , .
- API , API ( «» . 188). : API , API, .
, — . , — . , , . , .
API — , .
- , , , , . , .
- , , . , . , , .
. , , , .
« » - - , . XML/JSON. XML-, API JSON ( , , , ).
API API
API , , , API . , . , API! API API: «, API, API».
, , API API (, , API). API API. API ( — «» « API» ), API . , .
, , , , . , API API.
, API API , . , .
. , API . , , - API.
«», «», «» «» . , , . , - , . , . , , , , , . « API» « API» 9 .
, API, API, API .
API , — , . . . — , .
, : , API, API. , , , , , , , API API, API API. API , , .
. , API, , , . , -, .
API API, , , , -. , : , API , , , , .
, API , : API , . : , , API, , .
— API, OAuth.io APIDays — API, . API API, , , API - . API, «API : », 2015 API « ». , - HEC API.
, API . IETF W3C. , , EMC, Siemens CA Technologies.
. API UX , API .
, , , , - . API API , , , API .
»
»
»
25% —
APIe-mail .