book

API-Design, 2nd Edition

by Kai Spichale

May 2019

Intermediate to advanced

381 pages

9h 13m

German

dpunkt

Read now

Unlock full access

1.1 Eine kurze Geschichte der APIs1.2 Web-APIs ab dem Jahr 20001.3 API-Definition1.4 Vorteile einer API1.5 Nachteile einer API1.6 API als Produkt1.7 Welche Strategien verfolgen Unternehmen mit APIs?1.8 Zusammenfassung
2.1 Allgemeine Qualitätsmerkmale2.2 Benutzbarkeit2.2.1 Konsistent2.2.2 Intuitiv verständlich2.2.3 Dokumentiert2.2.4 Einprägsam und leicht zu lernen2.2.5 Lesbaren Code fördernd2.2.6 Schwer falsch zu benutzen2.2.7 Minimal2.2.8 Stabil2.2.9 Einfach erweiterbar2.3 Konnaszenz2.4 Zusammenfassung

3.1 Überblick3.2 Heuristiken und Trade-offs3.3 Anforderungen herausarbeiten3.4 Wenn Use Cases nicht ausreichen3.5 Entwurf mit Szenarien und Codebeispielen3.6 Spezifikation erstellen3.7 Reviews und Feedback3.8 Wiederverwendung3.9 Zusammenfassung
4.1 Implizite Objekt-API4.2 Utility-Bibliothek4.3 Service4.4 Framework4.5 Eine Frage der Priorität4.6 Zusammenfassung
5.1 Auswahl passender Namen5.1.1 Klassennamen5.1.2 Methodennamen5.1.3 Parameternamen5.1.4 Ubiquitäre Sprache5.1.5 Fazit5.2 Effektiver Einsatz von Typen5.2.1 Semantischen Vertrag minimieren5.2.2 Semantische Verletzung der Datenkapselung vermeiden5.2.3 Werden Namen überschätzt?5.2.4 Fazit5.3 Techniken für Objektkollaboration5.3.1 Tell, Don’t Ask5.3.2 Command/Query Separation5.3.3 Law of Demeter5.3.4 Platzierung von Methoden5.3.5 Fazit5.4 Jigsaw-Module5.5 Minimale Sichtbarkeit5.5.1 Jigsaw-Module5.5.2 Packages5.5.3 Klassen5.5.4 Methoden5.5.5 Felder5.5.6 Fazit5.6 Optionale Hilfsmethoden5.6.1 Komfort5.6.2 Utility-Klassen5.6.3 Fazit5.7 Optionale Rückgabewerte5.7.1 Ad-hoc-Fehlerbehandlung5.7.2 Null-Objekte5.7.3 Verwendung der Klasse java.util.Optional5.7.4 Fazit5.8 Exceptions5.8.1 Ausnahmesituationen5.8.2 Checked Exception versus Unchecked Exception5.8.3 Passende Abstraktionen5.8.4 Dokumentation von Exceptions5.8.5 Vermeidung von Exceptions5.8.6 Fazit5.9 Objekterzeugung5.9.1 Erzeugungsmuster der GoF5.9.2 Statische Factory-Methode5.9.3 Builder mit Fluent Interface5.9.4 Praktische Anwendung der Erzeugungsmuster5.9.5 Fazit5.10 Vererbung5.10.1 Ansätze zum Einsatz von Vererbung5.10.2 Stolperfallen bei Vererbung5.10.3 Bedeutung für API-Design5.10.4 Fazit5.11 Interfaces5.11.1 Typen nachrüsten5.11.2 Unterstützung für nicht triviale Interfaces5.11.3 Markierungsschnittstellen5.11.4 Funktionale Interfaces5.11.5 Fazit5.12 Zusammenfassung
6.1 Fluent Interface6.1.1 DSL-Grammatik6.1.2 Schachteln versus Verketten6.1.3 Fluent Interface von jOOQ6.1.4 Ist der Aufwand gerechtfertigt?6.1.5 Fazit6.2 Template-Methoden6.2.1 API versus SPI6.2.2 Erweiterbare Parameter6.2.3 Fazit6.3 Callbacks6.3.1 Synchrone Callbacks6.3.2 Asynchrone Callbacks6.3.3 Fazit6.4 Annotationen6.4.1 Auswertung zum Kompilierzeitpunkt6.4.2 Auswertung zur Laufzeit6.4.3 Fazit6.5 Wrapper-Interfaces6.5.1 Proxy6.5.2 Adapter6.5.3 Fassade6.5.4 Fazit6.6 Immutability6.6.1 Wiederverwendung6.6.2 Thread-Sicherheit6.6.3 Einfachheit6.6.4 Umsetzung6.6.5 Automatische Überprüfung mit dem Mutability Detector6.6.6 Codegenerierung mit Immutables6.6.7 Fazit6.7 Thread-sichere APIs6.7.1 Vorteile6.7.2 Nachteile6.7.3 Was bedeutet Thread-Sicherheit?6.7.4 Fazit6.8 Zusammenfassung
7.1 Kompatibilitätsstufen7.1.1 Code-Kompatibilität7.1.2 Binäre Kompatibilität7.1.3 Funktionale Kompatibilität7.2 Verwandtschaftsbeziehungen7.3 Design by Contract7.4 Codeänderungen7.4.1 Package-Änderungen7.4.2 Interface-Änderungen7.4.3 Klassenänderungen7.4.4 Spezialisierung von Rückgabetypen7.4.5 Generalisierung von Parametertypen7.4.6 Generics7.4.7 Ausnahmen7.4.8 Statische Methoden und Konstanten7.5 Praktische Techniken für API-Änderungen7.6 Test Compatibility Kit7.7 Zusammenfassung
8.1 REST versus HTTP8.2 REST-Grundprinzipien8.3 Ressourcen – die zentralen Bausteine8.4 HTTP-Methoden8.5 HATEOAS8.6 Zusammenfassung
9.1 Anwendungsbeispiel: Onlineshop9.2 URI-Design9.3 Medientypen9.4 Fehlerbehandlung9.5 Versionierung9.5.1 Daten- und Sprachversionierung9.5.2 Kompatibilität und Perspektive9.5.3 Versionsidentifikation9.6 Sicherheitsmechanismen9.7 Partielle Rückgaben9.8 GraphQL
9.10 Zusammenfassung
10.1 SOAP-Grundlagen10.2 WSDL-Grundlagen10.3 Entwurfsansätze und -muster10.4 Versionierung10.5 SOAP versus REST10.6 Zusammenfassung
11.1 Routenplanung für Lkw-Transporte (Teil 1)11.2 Message Broker11.3 Produkte11.4 Standards und Protokolle11.5 Routenplanung für Lkw-Transporte (Teil 2)11.6 Transaktionen und garantierte Nachrichtenzustellung11.7 Asynchrone Verarbeitung und REST11.8 Push Notifications11.9 Zusammenfassung
12.1 Motivation12.2 Zielgruppen unterscheiden12.3 Allgemeiner Aufbau12.4 Beispiele12.5 Dokumentation von Java-APIs12.6 Dokumentation von Web-APIs12.7 Zusammenfassung
13.1 Anwendungsfälle13.2 Performance-Vorteil13.3 Verdrängungsstrategien13.4 Cache-Strategien für Schreibzugriffe13.5 Cache-Topologien für Webanwendungen13.6 HTTP-Caching13.7 Zusammenfassung
14.1 Anwendungsfall14.2 Grundlagen14.3 Load Balancing14.4 Statuslose Kommunikation14.5 Skalierung von Datenbanken14.6 Skalierung von Messaging-Systemen14.7 Architekturvarianten14.8 Zusammenfassung
15.1 Consumer-Driven Contracts15.2 Backends for Frontends15.3 Vernachlässigte Frontend-Architektur15.4 Netflix-APIs15.5 Zusammenfassung
16.1 Überblick16.2 Funktionen einer API-Management-Plattform16.3 API-Management-Architektur16.4 Open-Source-Gateways16.5 Zusammenfassung

Overview

Mit Schnittstellen zum Zwecke der Arbeitsteilung, Wiederverwendung oder beispielsweise zur Bildung einer modularen Architektur haben Entwickler täglich zu tun. Häufig werden hierbei jedoch nur unbewusst durch Erfahrung erlernte Konzepte und Best-Practices genutzt.Dieses Buch schärft den Blick für APIs und erläutert, welche Eigenschaften effektive APIs haben sollten. Das Thema API-Design, das in anderen Büchern über Softwaredesign und Architektur als Querschnittsthema auftaucht, wird in diesem Buch umfassend behandelt.Nach der erfolgreichen Lektüre kennt der Leser die Grundlagenprinzipien von APIs und ist in der Lage, in professionellen Projekten APIs für Softwarekomponenten und Webservices zu entwerfen, zu dokumentieren und je nach Kompatibilitätsziel zu verändern.