Beherrschung der API-Architektur

Vorwort

Diese Arbeit wurde mithilfe von KI übersetzt. Wir freuen uns über dein Feedback und deine Kommentare: [e-mail]

Warum haben wir dieses Buch geschrieben?

Anfang 2020 nahmen wir an der O'Reilly Software Architecture in New York teil, wo Jim und Matt einen Workshop über APIs und einen Vortrag über API-Gateways hielten. Jim und Daniel kennen sich aus der Londoner Java-Community, und wie bei vielen Architekturveranstaltungen kamen wir zusammen, um über unsere Gedanken und unser Verständnis von API-Architekturen zu sprechen. Während wir uns auf dem Flur unterhielten, kamen mehrere Konferenzteilnehmer auf uns zu und sprachen über ihre Erfahrungen mit APIs. Die Leute fragten uns nach unseren Gedanken und Ratschlägen für ihre API-Reise. An diesem Punkt kam uns die Idee, ein Buch zum Thema APIs zu schreiben, um unsere Diskussionen auf Konferenzen mit anderen Architekten zu teilen.

Warum solltest du dieses Buch lesen?

Dieses Buch wurde so konzipiert, dass es ein vollständiges Bild von der Entwicklung, dem Betrieb und der Weiterentwicklung einer API-Architektur vermittelt. Wir haben unsere Erfahrungen und Ratschläge sowohl in unseren Texten als auch in einer begleitenden Fallstudie weitergegeben, die ein reales Event-Management-Konferenzsystem nachahmt, das es den Teilnehmern ermöglicht, Präsentationen zu sehen und zu buchen. Die Fallstudie zieht sich durch das gesamte Buch, damit du herausfinden kannst, wie sich abstrakte Konzepte manchmal in der Praxis umsetzen lassen. Wenn du einen Überblick über die Entwicklung der Fallstudie haben möchtest, findest du ihn in Kapitel 10.

Wir glauben auch daran, dass du deine eigenen Entscheidungen treffen kannst. Um dies zu unterstützen, werden wir:

• Sei deutlich, wenn wir eine klare Empfehlung oder Anleitung haben.

• Hebe Bereiche hervor, in denen du vorsichtig sein solltest, und Probleme, auf die du stoßen könntest.

• Bereitstellung eines Leitfadens für Architekturentscheidungen (ADR)¹ um dir zu helfen, die bestmögliche Entscheidung unter den Umständen deiner Architektur zu treffen und eine Anleitung zu geben, was zu beachten ist (denn manchmal lautet die Antwort "es kommt darauf an").

• Hebe Referenzen und nützliche Artikel hervor, in denen du tiefer gehendeInhalte finden kannst.

Das Buch ist kein reines Technologiebuch. Wir waren der Meinung, dass die Abdeckung bestehender Architekturen mit einem evolutionären Ansatz hin zu besser geeigneten API-Architekturen den größten Nutzen für dich bringen würde. Wir haben auch versucht, einen Ausgleich zu schaffen und einen Blick auf neuere Technologien und Entwicklungen im Bereich der API-Architektur zu werfen.

Für wen dieses Buch ist

Obwohl wir bei der Erstellung dieses Buches zunächst eine Persona im Sinn hatten, kristallisierten sich während des Schreib- und Überarbeitungsprozesses drei wichtige Personas heraus: der Entwickler, der zufällige Architekt und der Lösungs- oder Unternehmensarchitekt. Wir haben diese Personas in den folgenden Abschnitten skizziert, damit du dich nicht nur mit mindestens einer von ihnen identifizieren kannst, sondern auch, damit du jedes Kapitel durch die unterschiedliche Brille dieser Personas betrachten kannst.

Entwickler

Du hast wahrscheinlich schon mehrere Jahre lang professionell programmiert und kennst dich mit den gängigen Herausforderungen, Mustern und bewährten Methoden der Softwareentwicklung aus. Du erkennst zunehmend, dass die Entwicklung serviceorientierter Architekturen (SOA) und die Einführung von Cloud-Diensten dazu führen, dass die Erstellung und der Betrieb von APIs zu einer Kernkompetenz werden. Du möchtest mehr über die Gestaltung und das Testen effektiver APIs erfahren. Du möchtest die verschiedenen Implementierungsmöglichkeiten (z.B. synchrone oder asynchrone Kommunikation) und Technologien kennenlernen und lernen, die richtigen Fragen zu stellen und zu bewerten, welcher Ansatz in einem bestimmten Kontext der beste ist.

Zufälliger Architekt

Wahrscheinlich entwickelst du schon seit vielen Jahren Software und warst oft als Teamleiter oder Softwarearchitekt tätig (auch wenn du die offiziellen Titel nicht trägst). Du verstehst zentrale Architekturkonzepte wie Design für hohe Kohäsion und lose Kopplung und wendest diese auf alle Aspekte der Softwareentwicklung an, einschließlich Design, Tests und Betriebssysteme.

Du erkennst, dass sich deine Aufgabe zunehmend darauf konzentriert, Systeme zu kombinieren, um die Anforderungen der Kunden zu erfüllen. Dazu können intern entwickelte Anwendungen und SaaS-Angebote von Dritten gehören. APIs spielen eine große Rolle bei der erfolgreichen Integration deiner Systeme mit externen Systemen. Du möchtest mehr über die unterstützenden Technologien (z. B. API-Gateway, Service Mesh usw.) erfahren und auch verstehen, wie man API-basierte Systeme betreibt und sichert.

Lösungen/Enterprise Architect

Du entwirfst und entwickelst seit mehreren Jahren Unternehmenssoftwaresysteme und hast höchstwahrscheinlich das Wort " Architekt" in deiner Berufsbezeichnung oder Rollenbeschreibung. Du bist für das Gesamtbild der Softwareentwicklung verantwortlich und arbeitest in der Regel im Kontext einer großen Organisation oder einer Reihe großer, miteinander verbundener Organisationen.

Du erkennst die Veränderungen, die die neueste Generation von servicebasierten Architekturstilen auf das Design, die Integration und die Verwaltung von Software hat, und du siehst, dass APIs für den Erfolg der Software-Strategie deines Unternehmens von zentraler Bedeutung sind. Du möchtest mehr über evolutionäre Muster erfahren und verstehen, wie sich die Wahl des API-Designs und der Implementierung darauf auswirkt. Außerdem möchtest du dich auf die funktionsübergreifenden "ilities" - Nutzbarkeit, Wartbarkeit, Skalierbarkeit und Verfügbarkeit - konzentrieren und verstehen, wie man API-basierte Systeme baut, die diese Eigenschaften aufweisen und auch Sicherheit bieten.

Was du lernen wirst

Nachdem du dieses Buch gelesen hast, wirst du es verstehen:

• Die Grundlagen von REST-APIs und wie man APIs am besten erstellt, versioniert und testet

• Die Architekturmuster beim Aufbau einer API-Plattform

• Die Unterschiede bei der Verwaltung des API-Verkehrs am Ingress und in der Service-to-Service-Kommunikation und die Anwendung von Mustern und Technologien wie API-Gateways und Service-Meshes

• Bedrohungsmodellierung und wichtige Sicherheitsüberlegungen für APIs, wie Authentifizierung, Autorisierung und Verschlüsselung

• Wie man bestehende Systeme in Richtung APIs und andere Zielsysteme, wie die Cloud, weiterentwickelt

Und du wirst in der Lage sein:

• Entwirf, entwickle und teste API-basierte Systeme

• Hilf dabei, das API-Programm einer Organisation aus einer architektonischen Perspektive zu implementieren und voranzutreiben

• Einsatz, Freigabe und Konfiguration von Schlüsselkomponenten einer API-Plattform

• Einsatz von Gateways und Dienstnetzen auf der Grundlage von Fallstudien

• Identifiziere Schwachstellen in der API-Architektur und setze angemessene Sicherheitsmaßnahmen um

• Beitrag zu neuen API-Trends und den dazugehörigen Communities

Was dieses Buch nicht ist

Wir sind uns bewusst, dass APIs einen riesigen Markt umfassen, und wir möchten klarstellen, was in diesem Buch nicht behandelt wird. Das heißt nicht, dass wir diese Themen nicht für wichtig halten; wenn wir jedoch versuchen würden, alles abzudecken, könnten wir unser Wissen nicht effektiv mit dir teilen.

Wir werden Anwendungsmuster für die Migration und Modernisierung behandeln, die die Nutzung von Cloud-Plattformen einschließen, aber das Buch ist nicht ausschließlich auf Cloud-Technologien ausgerichtet. Viele von euch werden hybride Architekturen haben oder sogar alle ihre Systeme in Rechenzentren hosten. Wir wollen sicherstellen, dass wir die Design- und Betriebsfaktoren von API-Architekturen abdecken, die beide Ansätze unterstützen.

Das Buch ist nicht an eine bestimmte Sprache gebunden, sondern zeigt anhand von einfachen Beispielen, wie man APIs und die dazugehörige Infrastruktur entwickelt. Das Buch konzentriert sich mehr auf die Herangehensweise, und die Codebeispiele sind im zugehörigen GitHub-Repository verfügbar.

In diesem Buch wird kein Architekturstil gegenüber einem anderen bevorzugt, aber wir werden Situationen diskutieren, in denen Architekturansätze zu Einschränkungen des vorgestellten API-Angebots führen können.

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 Tipp oder eine Anregung.

Hinweis

Dieses Element steht für einen allgemeinen Hinweis.

Warnung

Dieses Element weist auf eine Warnung oder einen Warnhinweis hin.

Code-Beispiele verwenden

Zusätzliches Material (Code-Beispiele, Übungen usw.) steht unter https://github.com/masteringapi zum Download bereit .

Wenn du eine technische Frage oder ein Problem mit den Codebeispielen hast, schicke bitte eine E-Mail an [e-mail].

Dieses Buch soll dir helfen, deine Arbeit zu erledigen. Wenn in diesem Buch Beispielcode angeboten wird, darfst du ihn in deinen Programmen und deiner Dokumentation verwenden. Du musst uns nicht um Erlaubnis fragen, es sei denn, du reproduzierst einen großen Teil des Codes. Wenn du zum Beispiel ein Programm schreibst, das mehrere Teile des Codes aus diesem Buch verwendet, brauchst du keine Erlaubnis. Der Verkauf oder die Verbreitung von Beispielen aus O'Reilly-Büchern erfordert jedoch eine Genehmigung. Die Beantwortung einer Frage mit einem Zitat aus diesem Buch und einem Beispielcode erfordert keine Genehmigung. Wenn du einen großen Teil des Beispielcodes aus diesem Buch in die Dokumentation deines Produkts aufnimmst, ist eine Genehmigung erforderlich.

Wir freuen uns über eine Namensnennung, verlangen sie aber in der Regel nicht. Eine Quellenangabe umfasst normalerweise den Titel, den Autor, den Verlag und die ISBN. Ein Beispiel:"Mastering API Architecture" von James Gough, Daniel Bryant, und Matthew Auburn (O'Reilly). Copyright 2023 James Gough Ltd, Big Picture Tech Ltd, and Matthew Auburn Ltd, 978-1-492-09063-2."

Wenn du der Meinung bist, dass deine Verwendung von Codebeispielen nicht unter die Fair-Use-Regelung oder die oben genannte Erlaubnis fällt, kannst du uns gerne unter [e-mail] kontaktieren .

O'Reilly Online Learning

Hinweis

Seit mehr als 40 Jahren bietet O'Reilly Media Schulungen, Wissen und Einblicke in Technologie und Wirtschaft, um Unternehmen zum Erfolg zu verhelfen.

Unser einzigartiges Netzwerk von Experten und Innovatoren teilt sein Wissen und seine Erfahrung durch Bücher, Artikel und unsere Online-Lernplattform. Die Online-Lernplattform von O'Reilly bietet dir On-Demand-Zugang zu Live-Trainingskursen, ausführlichen Lernpfaden, interaktiven Programmierumgebungen und einer umfangreichen Text- und Videosammlung von O'Reilly und über 200 anderen Verlagen. Weitere Informationen erhältst du unter https://oreilly.com.

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://oreil.ly/Mastering-API-Architecture aufrufen .

Schreib eine E-Mail an [e-mail], um Kommentare oder technische Fragen zu diesem Buch zu stellen.

Neuigkeiten und Informationen über unsere Bücher und Kurse findest du unter https://oreilly.com.

Du findest uns auf LinkedIn: https://linkedin.com/company/oreilly-media.

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

Sieh uns auf YouTube: https://www.youtube.com/oreillymedia.

Danksagungen

Wie bei fast allen Fachbüchern stehen auch bei diesem Buch nur drei Namen als Autoren auf der Vorderseite, aber in Wirklichkeit haben viele Menschen dazu beigetragen, entweder direkt in Form von Feedback während der Erstellung des Buches oder indirekt durch ihre Lehre und Anleitung im Laufe der Jahre.

Obwohl wir unmöglich alle aufzählen können, die uns auf dieser Reise geholfen haben, möchten wir uns ausdrücklich bei denjenigen bedanken, die sich die Zeit genommen haben, um uns mit ausführlichen Diskussionen, Feedback und Unterstützung zu unterstützen.

Unsere technischen Prüfer: Sam Newman, Dov Katz, Sarah Wells, Antoine Cailliau, Stefania Chaplin, Matt McLarty, und Neal Ford.

Für allgemeine Details, Ermutigung, Ratschläge und Einführungen: Charles Humble, Richard Li, Simon Brown, Nick Ebbitt, Jason Morgan, Nic Jackson, Cliff Tiltman, Elspeth Minty, George Ball, Benjamin Evans und Martijn Verberg.

Das O'Reilly-Team: Virginia Wilson, Melissa Duffield und Nicole Tache.

James Gough

Ich möchte mich bei meiner unglaublichen Familie bedanken: Megan, Emily und Anna. Ohne ihre Hilfe und Unterstützung wäre das Schreiben nicht möglich gewesen. Ich möchte auch meinen Eltern Heather und Paul dafür danken, dass sie mich zum Lernen ermutigt undmich immerunterstützt haben.

Ich möchte mich bei meinen Co-Autoren Daniel und Matt bedanken. Ein Buch zu schreiben ist eine Herausforderung und, wie die Architektur, nie perfekt. Es war eine unterhaltsame Reise und wir haben alle viel voneinander und von unseren tollen Rezensenten gelernt. Schließlich möchte ich Jon Daplyn, Ed Safo, David Halliwell und Dov Katz dafür danken, dass sie mich während meiner gesamten Karriere unterstützt, gefördert und ermutigt haben.

Daniel Bryant

Ich möchte meiner gesamten Familie für ihre Liebe und Unterstützung danken, sowohl während des Schreibprozesses als auch während meiner gesamten Karriere. Ich möchte auch Jim und Matt dafür danken, dass sie mich auf dieser Reise als Autoren unterstützt haben. Wir begannen mit diesem Buch Anfang 2020, gerade als die Pandemie ausbrach. Unsere wöchentlichen Telefonate am Mittwochmorgen waren nicht nur nützlich für die Zusammenarbeit, sondern auch eine großartige Quelle für Spaß und Unterstützung, als sich unsere Welten schnell veränderten. Abschließend möchte ich allen Beteiligten der London Java Community (LJC), den InfoQ/QCon-Teams und allen bei Ambassador Labs danken. Diese drei Gemeinschaften haben mir Zugang zu Mentoren, Anleitung und so vielen Möglichkeiten verschafft. Ich hoffe, dass ich all dies eines Tages weitergeben kann.

Matthew Auburn

Ich möchte mich bei meiner wunderbaren Frau Hannah bedanken - ohne ihre Unterstützung hätte ich dieses Buch nicht schreiben können. Ich danke meinen beiden Eltern, die mir gezeigt haben, dass alles möglich ist und die nie aufgehört haben, an mich zu glauben. Die Arbeit an diesem Buch war eine unglaubliche Erfahrung, und Jim und Dan, ihr wart beide hervorragende Mentoren. Ihr beide habt mir so viel beigebracht und mir geholfen, das bestmögliche Material zu schreiben. Ein weiterer Dank geht an Jim - du hast mir das Reden beigebracht und mir mehr geholfen als jeder andere in meiner Karriere. Und schließlich und vor allem möchte ich meinem Sohn Joshi danken: Du bist eine absolute Freude.

¹ In der Einleitung erfährst du mehr über ADRs und ihre Bedeutung für das Treffen und Dokumentieren von Architekturentscheidungen.