APIs
Die Entwurfsentscheidungen hinter Schnittstellen.
Was APIs umfasst
Eine API ist der Vertrag, über den Systeme miteinander sprechen. Diese Kategorie behandelt API-Design, Versionierung und die Wahl zwischen REST, GraphQL und gRPC.
Was diese Kategorie abdeckt
- REST vs. GraphQL vs. gRPC
- API-Versionierung ohne Brüche
- API-Design: Idempotenz, Pagination, Fehler
- Zuverlässige Webhooks bauen
Belastbare Antworten in diesem Feld.
Tiefe, referenzierbare Dokumente — jede Empfehlung mit Trade-off, Kosten und dem Fall, in dem wir anders entscheiden.
Idempotenz in verteilten Systemen
Warum verteilte Systeme doppelte Nachrichten ertragen müssen und wie man sie idempotent macht: Idempotency Keys, Retries, Outbox und Inbox.
API Design für langlebige Systeme
Wie man APIs entwirft, die Jahre überdauern, ohne die Systeme ihrer Nutzer zu brechen: Verträge, Kompatibilität, Versionierung, Fehler, Evolution.
REST, GraphQL oder RPC — die Wahl des API-Stils
Die Wahl des API-Stils nach Passung statt Mode: Was REST, GraphQL und RPC unterscheiden, welche Problemform zu welchem Stil passt, was jeder kostet.
API-Versionierung ohne Kunden zu brechen
Wie man eine API über Jahre weiterentwickelt, ohne die Systeme der Kunden zu brechen: kompatibel erweitern, sauber versionieren, Deprecation als Prozess.
Gelernte Lektionen in diesem Feld.
Fehler und was sie uns gelehrt haben — anonym, ohne Drama. Der Fehler ist der Lehrer.
Die Beiträge dieser Kategorie erscheinen fortlaufend. Grundbegriffe finden Sie schon heute im Glossar.
Zum GlossarVerwandte Themen.
Leitfäden, Entscheidungen, Leistungen und Arbeiten, die mit dieser Seite zusammenhängen.
Leistungen
Verwandte Konzepte
Architekturentscheidungen
Playbooks
Ein konkretes Problem in diesem Feld?
Wir lösen es nicht nur auf dem Papier. Sprechen Sie mit den Ingenieuren, die es bauen würden.
