Sofortantwort
OpenAPI / Swagger einfach erklärt
Standard für maschinenlesbare API-Dokumentation.
- Kurz gesagt
- Maschinenlesbares Format (YAML/JSON) zur API-Beschreibung
- Typischer Einsatz
- API-Dokumentation, Code-Generierung, API-Testing
- Wichtig zu wissen
- Ermöglicht Code-Generierung für Clients und Server
OpenAPI / Swagger im Überblick
OpenAPI ist ein Standard, um REST-APIs zu beschreiben. Statt Dokumentation manuell zu schreiben, definierst du die API in einem strukturierten Format – und Tools generieren Docs, Tests und Code automatisch.
Vorher (ohne OpenAPI):
Dokumentation: Word-Dokument, veraltet nach 2 Wochen
Testing: Postman-Collection, manuell gepflegt
Client-Code: Jeder schreibt eigenen HTTP-Code
Nachher (mit OpenAPI):
openapi.yaml → Swagger UI (Docs)
→ Postman Import (Testing)
→ SDK Generator (Client-Code)
→ Server Stubs (Backend)
Beispiel OpenAPI-Spec:
openapi: 3.1.0
info:
title: User API
version: 1.0.0
paths:
/users/{id}:
get:
summary: Get user by ID
parameters:
- name: id
in: path
required: true
schema:
type: integer
responses:
'200':
description: User found
content:
application/json:
schema:
$ref: '#/components/schemas/User'
'404':
description: User not found
components:
schemas:
User:
type: object
properties:
id:
type: integer
name:
type: string
email:
type: string
format: email
Technisch betrachtet
OpenAPI-Struktur
openapi: 3.1.0 # Version
info: # Metadaten
title: My API
version: 1.0.0
description: API description
servers: # Basis-URLs
- url: https://api.example.com/v1
paths: # Endpunkte
/resource:
get: ...
post: ...
components: # Wiederverwendbare Teile
schemas: ... # Datenmodelle
parameters: ... # Parameter
responses: ... # Response-Definitionen
securitySchemes: ... # Auth-Methoden
security: # Globale Security
- bearerAuth: []
Authentifizierung definieren
components:
securitySchemes:
bearerAuth:
type: http
scheme: bearer
bearerFormat: JWT
apiKey:
type: apiKey
in: header
name: X-API-Key
oauth2:
type: oauth2
flows:
authorizationCode:
authorizationUrl: https://auth.example.com/authorize
tokenUrl: https://auth.example.com/token
scopes:
read: Read access
write: Write access
security:
- bearerAuth: []
Request/Response Bodies
paths:
/users:
post:
summary: Create user
requestBody:
required: true
content:
application/json:
schema:
type: object
required:
- name
- email
properties:
name:
type: string
minLength: 1
maxLength: 100
email:
type: string
format: email
example:
name: "Max Mustermann"
email: "max@example.com"
responses:
'201':
description: User created
content:
application/json:
schema:
$ref: '#/components/schemas/User'
Code-Generierung
Client generieren:
openapi-generator generate \
-i openapi.yaml \
-g typescript-axios \
-o ./generated-client
Unterstützte Sprachen (Auswahl):
- TypeScript (Axios, Fetch, Angular)
- Python (requests, aiohttp)
- Java (OkHttp, Retrofit)
- Go, Rust, C#, Ruby, PHP…
Spec-First vs. Code-First
| Ansatz | Beschreibung | Vorteile |
|---|---|---|
| Spec-First | Erst Spec schreiben, dann implementieren | Sauberer Contract, bessere Planung |
| Code-First | Spec aus Code generieren | Schneller, immer synchron |
Code-First Beispiel (FastAPI):
from fastapi import FastAPI
from pydantic import BaseModel
app = FastAPI()
class User(BaseModel):
id: int
name: str
email: str
@app.get("/users/{user_id}", response_model=User)
async def get_user(user_id: int):
...
# OpenAPI-Spec automatisch unter /openapi.json
Validierung
# Spec validieren
npx @redocly/cli lint openapi.yaml
# Request/Response gegen Spec validieren
# (in Tests oder als Middleware)Schritt für Schritt
Eine OpenAPI-Spezifikation als gemeinsamen Vertrag nutzen
Der Wert einer Spezifikation entsteht, wenn sie Entscheidungen vereinheitlicht und automatisch überprüfbar macht.
Nutzer und Abläufe verstehen
01
Kläre, welche Clients die Schnittstelle nutzen und welche Ressourcen, Eingaben und Fehlerfälle sie benötigen.
Client → Aufgabe → Endpoint → erwartete AntwortVertrag im Schema definieren
02
Beschreibe Endpunkte, Parameter, Datenmodelle, Authentifizierung und Antworten präzise in der Spezifikation.
paths + operationId + requestBody + responsesBeispiele und Fehlerfälle ergänzen
03
Konkrete Beispiele verhindern Missverständnisse und machen Integrationen schneller testbar.
Erfolg + Validierungsfehler + fehlende Rechte + KonfliktImplementierung gegen den Vertrag prüfen
04
Automatisierte Tests oder Contract Checks erkennen Abweichungen zwischen Dokumentation und laufender API.
Spec ↔ Server ↔ Test ↔ ClientÄnderungen bewusst veröffentlichen
05
Versionshinweise, Migrationsregeln und eine kompatible Weiterentwicklung schützen bestehende Nutzer.
Änderung → Kompatibilitätscheck → Release Notes
Konkretes Beispiel
Beispiel: Partner-API für Bestellungen
Externe Systeme sollen Bestellungen anlegen und ihren Status abfragen.
Integrationsbedarf
Partner brauchen verlässliche Angaben zu Feldern, Berechtigungen, Fehlern und dem Ablauf nach einer fehlgeschlagenen Anfrage.
Maschinenlesbarer Vertrag
Eine OpenAPI-Datei mit Datenmodellen, Sicherheitsanforderungen, Beispielen und automatisierten Checks gegen die Implementierung.
Wenn Spezifikation, Tests und Dokumentation dieselbe Quelle nutzen, sinkt die Gefahr widersprüchlicher Schnittstelleninformationen.
Einordnung
Vorteile und Grenzen
Das spricht dafür
- Klare Zusammenarbeit: Fachseite, Backend und API-Nutzer teilen einen präzisen Vertrag.
- Automatisierbar: Dokumentation, Tests und teilweise Client-Code können aus derselben Beschreibung entstehen.
- Früheres Feedback: Schnittstellen lassen sich diskutieren, bevor die gesamte Implementierung fertig ist.
Das solltest du beachten
- Pflegeaufwand: Eine nicht aktualisierte Spezifikation schafft mehr Verwirrung als gar keine.
- Detailarbeit nötig: Gute Modelle, Fehlerantworten und Sicherheitsdefinitionen verlangen Sorgfalt.
- Nicht jede Frage ist Schema: Betriebsgrenzen und Produktentscheidungen brauchen zusätzliche Dokumentation.
Vertiefung · für FortgeschritteneEine Spezifikation, viele Anwendungen
Die OpenAPI-Datei verbindet Design, Implementierung, Tests und Kommunikation über dieselbe Schnittstelle.
Maschinenlesbare Beschreibung von Endpunkten, Daten und Sicherheitsanforderungen.