Vorwort

Diese Arbeit wurde mithilfe von KI übersetzt. Wir freuen uns über dein Feedback und deine Kommentare: translation-feedback@oreilly.com

Der Aufbau einer beliebten Entwicklerplattform mit einer API, die von Millionen von Entwicklern genutzt wird, ist eines der anspruchsvollsten und aufregendsten Unterfangen, das du in deiner Softwarekarriere angehen kannst. In diesem Buch erfährst du, wie du das anstellen kannst.

APIs sind das Herzstück der modernen Softwareentwicklung. Sie lösen ein grundlegendes Problem der Entwickler: Wie kann ich als Softwareentwickler den Code, den ich geschrieben habe, anderen Entwicklern zugänglich machen, damit sie ihn nutzen und weiterentwickeln können? Die Entwicklung von Software in der modernen Welt ist ähnlich wie das Bauen mit LEGO-Steinen. Als Entwickler hast du Zugang zu einer großen Anzahl von APIs, die Dienste wie Zahlungen, Kommunikation, Autorisierung und Authentifizierung usw. bereitstellen. Wenn du neue Software entwickelst, ist es deine Aufgabe als Softwareentwickler/in, diese APIs zu nutzen, um dein neues Produkt zusammenzustellen und dabei Code wiederzuverwenden, den andere entwickelt haben.

Viele Softwareentwickler/innen, die als Kinder gerne mit LEGOs gespielt haben, spielen auch heute noch gerne mit ihnen. Und wer würde das nicht? Es macht Spaß, und du kannst nützliche Dinge mit tollen bunten Teilen bauen, die sich nahtlos miteinander verbinden lassen. Aber was wäre, wenn du das LEGO selbst bauen könntest? Wäre es nicht toll, wenn du nicht nur neue LEGO Bausätze erfinden könntest, sondern auch die LEGO Teile selbst, und andere damit innovativ sein lassen könntest? Wenn du deine eigene API baust, erschaffst du im Grunde deine eigenen LEGO Teile, die andere Entwickler/innen verwenden können.

APIs sind kein neues Konzept in der Informatik. In den 60er Jahren begannen Entwickler, Standardbibliotheken für die ersten prozeduralen Sprachen zu erstellen und diese mit anderen Entwicklern zu teilen. Diese Entwickler konnten die Standardfunktionen dieser Bibliotheken nutzen, ohne deren internen Code zu kennen.

In den 70er und 80er Jahren, mit dem Aufkommen von Netzwerkcomputern, kamen dann die ersten Netzwerk-APIs auf, die Dienste zur Verfügung stellten, die Entwickler über Remote Procedure Calls (RPCs) nutzen konnten. Mit RPCs konnten Entwickler ihre Funktionen über das Netzwerk bereitstellen und entfernte Bibliotheken so aufrufen, als ob sie lokal wären. Programmiersprachen wie Java sorgten für eine weitere Abstraktion und Komplexität mit Messaging-Middleware-Servern, die diese Remote-Dienste auflisteten und orchestrierten.

In den 90er Jahren, als das Internet aufkam, wollten viele Unternehmen die Art und Weise, wie wir APIs erstellen und bereitstellen, standardisieren. Standards wie die Common Object Request Broker Architecture (CORBA), das Component Object Model (COM) und das Distributed Component Object Model (DCOM) von Microsoft und viele andere versuchten, sich als De-facto-Methode für die Bereitstellung von Diensten über das Internet durchzusetzen. Das Problem war, dass die meisten dieser Standards kompliziert zu verwalten waren, ähnliche Programmiersprachen auf beiden Seiten des Netzwerks voraussetzten und manchmal die lokale Installation eines Teils des entfernten Dienstes (allgemein als _stub_ bezeichnet) erforderten, um darauf zugreifen zu können. Der Traum von der Interoperabilität wurde bald zu einem Albtraum aus Konfigurationen und Einschränkungen.

In den späten 90er und frühen 00er Jahren kamen offenere und standardisierte Möglichkeiten für den Zugriff auf Remote-Dienste über das Internet (Web-APIs) auf. Zuerst mit dem Simple Object Access Protocol (SOAP) und der Extensible Markup Language (XML), dann mit dem Representative State Transfer (REST) und der JavaScript Object Notation (JSON) wurde der Zugriff auf Dienste einfacher und standardisierter, ohne dass man auf clientseitigen Code oder eine Programmiersprache angewiesen war. In diesem Buch behandeln wir die beliebtesten und nützlichsten dieser Methoden.

Ein Technologieunternehmen nach dem anderen begann, nützliche Dienste über APIs anzubieten - von den Anfängen der Amazon Affiliate API (2002) über die Flickr API (2004) und die Google Maps API (2005) bis hin zur Yahoo! Pipes API (2007) gibt es heute Tausende von APIs, die jeden erdenklichen Dienst anbieten, von der Bildbearbeitung bis zur künstlichen Intelligenz. Entwickler/innen können diese aufrufen und neue Produkte erstellen, die aus mehreren APIs zusammengesetzt sind, so wie man mit LEGO-Steinen baut.

Obwohl APIs zu einem Allgemeingut und ihre Nutzung zu einer einfachen Aufgabe geworden sind, ist die Erstellung einer API immer noch eine Kunstform. Nimm diese Herausforderung nicht auf die leichte Schulter; eine solide API zu erstellen ist nicht einfach. APIs sollten genial einfach und hochgradig interoperabel sein - wie bei LEGO sollte jedes Teil eines Baukastens mit jedem anderen Teil eines anderen Baukastens gut funktionieren. APIs sollten auch von Entwicklerprogrammen und Ressourcen begleitet werden, die Entwicklern helfen, sie zu übernehmen. Die Entwicklung einer soliden API ist nur der erste Schritt; du musst auch ein florierendes Ökosystem von Entwicklern aufbauen und unterstützen. Auf diese Herausforderungen gehen wir im letzten Teil dieses Buches ein.

Wir haben dieses Buch geschrieben, weil wir festgestellt haben, dass wir im Laufe unserer Karriere ähnliche Prozesse verfolgt und ähnliche Entscheidungen, Prozesse und Optimierungen für viele APIs getroffen haben, diese Richtlinien aber nicht in einer einzigen maßgeblichen Ressource zusammengefasst waren. Jeder von uns konnte hier und da auf Blogposts oder Artikel zu einzelnen Themen verweisen, aber es gab keine Stelle, die beschrieb, wie man für die Entwicklung und das Wachstum von Web-APIs und ihren Ökosystemen designt. Mit diesem Buch möchten wir dir alle Werkzeuge an die Hand geben, die wir im Laufe unserer Karriere bei der Entwicklung von APIs entwickelt und entdeckt haben. Der Zugang zu diesem Wissen ist sehr wertvoll. Es kann den Unterschied zwischen Erfolg und Misserfolg deines Unternehmens oder deiner Technologie ausmachen, und es kann der einzigartige Vorteil sein, der deine Karriere vorantreibt.

Wie dieses Buch organisiert ist

Dieses Buch besteht aus drei großen Teilen:

Theorie (Kapitel 1-4): Hier behandeln wir die grundlegenden Konzepte für die Erstellung einer API, besprechen verschiedene API-Muster und diskutieren verschiedene Aspekte einer guten API.
Praxis (Kapitel 5-7): In diesen Kapiteln sprechen wir darüber, wie man eine API tatsächlich entwirft und ihren Betrieb in der Produktion verwaltet.
Entwicklerliebe (Kapitel 8-11): In diesem Abschnitt gehen wir über die Entwicklung einer API hinaus und zeigen dir, wie du ein florierendes Entwickler-Ökosystem um deine API herum aufbauen kannst.

Außerdem enthält dieses Buch Fallstudien (Lektionen von Stripe, Slack, Twitch, Microsoft, Uber, GitHub, Facebook, Cloudinary, Oracle und mehr!), Ratschläge und Profi-Tipps von Experten auf diesem Gebiet und Geschichten über Erfahrungen aus dem wirklichen Leben. Im Anhang A findest du einige praktische Arbeitsblätter, Templates und Checklisten.

In diesem Buch verwendete Konventionen

In diesem Buch werden die folgenden typografischen Konventionen verwendet:

Kursiv: Weist auf neue Begriffe, URLs, E-Mail-Adressen, Dateinamen und Dateierweiterungen hin.
Constant width: Wird für Programmlistings sowie innerhalb von Absätzen verwendet, um auf Programmelemente wie Variablen- oder Funktionsnamen, Datenbanken, Datentypen, Umgebungsvariablen, Anweisungen und Schlüsselwörter hinzuweisen.
Constant width bold: Zeigt Befehle oder anderen Text an, der vom Benutzer wortwörtlich eingetippt werden sollte.
Constant width italic: Zeigt Text an, der durch vom Benutzer eingegebene Werte oder durch kontextabhängige Werte ersetzt werden soll.

Tipp

Dieses Element steht für einen "Profi-Tipp".

Hinweis

Dieses Element steht für einen allgemeinen Hinweis.

Warnung

Dieses Element weist auf eine Warnung oder einen Warnhinweis hin.

O'Reilly Safari

Hinweis

Safari (ehemals Safari Books Online) ist eine mitgliederbasierte Schulungs- und Nachschlageplattform für Unternehmen, Behörden, Lehrkräfte und Einzelpersonen.

Mitglieder haben Zugang zu Tausenden von Büchern, Schulungsvideos, Lernpfaden, interaktiven Tutorials und kuratierten Playlists von über 250 Verlagen, darunter O'Reilly Media, Harvard Business Review, Prentice Hall Professional, Addison-Wesley Professional, Microsoft Press, Sams, Que, Peachpit Press, Adobe, Focal Press, Cisco Press, John Wiley & Sons, Syngress, Morgan Kaufmann, IBM Redbooks, Packt, Adobe Press, FT Press, Apress, Manning, New Riders, McGraw-Hill, Jones & Bartlett und Course Technology, um nur einige zu nennen.

Weitere Informationen erhältst du unter http://oreilly.com/safari.

Wie du uns kontaktierst

Bitte richte Kommentare und Fragen zu diesem Buch an den Verlag:

O'Reilly Media, Inc.
1005 Gravenstein Highway Nord
Sebastopol, CA 95472
800-998-9938 (in den Vereinigten Staaten oder Kanada)
707-829-0515 (international oder lokal)
707-829-0104 (Fax)

Wir haben eine Webseite für dieses Buch, auf der wir Errata, Beispiele und zusätzliche Informationen auflisten. Du kannst diese Seite unter https://bit.ly/designing-web-apis aufrufen .

Wenn du Kommentare oder technische Fragen zu diesem Buch stellen möchtest, sende eine E-Mail an bookquestions@oreilly.com.

Weitere Informationen zu unseren Büchern, Kursen, Konferenzen und Neuigkeiten findest du auf unserer Website unter http://www.oreilly.com.

Finde uns auf Facebook: http://facebook.com/oreilly

Folge uns auf Twitter: http://twitter.com/oreillymedia

Schau uns auf YouTube: http://www.youtube.com/oreillymedia

Danksagungen

Danke an unsere Familien, deren Liebe und Unterstützung dieses Buch möglich gemacht haben.

Besonderen Dank an unsere technischen Prüfer Bilal Aijazi, James Higgenbotham, Jenny Donnelly, Margaret Le und Melissa Khuat.

Vielen Dank auch an Eric Conlon, Or Weis, Taylor Singletary und Zoe Madden-Wood, die zusätzliche Kommentare und Rückmeldungen gegeben haben.

Abschließend möchte ich mich bei allen bedanken, die an Interviews und Fallstudien teilgenommen und auf andere Weise zur Entstehung dieses Buches beigetragen haben:

Bilal Aijazi, CTO bei Polly
Chris Messina, Leiter der Entwicklererfahrung bei Uber
Desiree Motamedi Ward, Leiterin des Produktmarketings für Entwickler bei Facebook
Ido Green, Anwalt der Entwickler bei Google
Kyle Daigle, Director of Ecosystem Engineering bei GitHub
Ran Rubinstein, VP für Lösungen bei Cloudinary
Romain Huet, Leiter der Entwicklerbeziehungen bei Stripe
Ron Reiter, Senior Director of Engineering bei Oracle
Taylor Singletary, leitender Inhaltsautor bei Slack
Yochay Kiriaty, Azure Principal Program Manager bei Microsoft