OpenAPI / Swagger

Wie eine API-Spezifikation aus Dokumentation einen überprüfbaren Vertrag für Entwicklung, Tests und Betrieb macht.

Ein Standard zur Beschreibung von REST-APIs – ermöglicht automatische Dokumentation, Code-Generierung und API-Testing.

Fortgeschritten2 Min Lesezeit

Erklärung starten

Auf einen Blick

3 Punkte

  1. Maschinenlesbares Format (YAML/JSON) zur API-Beschreibung
  2. Swagger UI generiert interaktive Dokumentation automatisch
  3. Ermöglicht Code-Generierung für Clients und Server

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

AnsatzBeschreibungVorteile
Spec-FirstErst Spec schreiben, dann implementierenSauberer Contract, bessere Planung
Code-FirstSpec aus Code generierenSchneller, 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.

  1. 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 Antwort
  2. Vertrag im Schema definieren

    02

    Beschreibe Endpunkte, Parameter, Datenmodelle, Authentifizierung und Antworten präzise in der Spezifikation.

    paths + operationId + requestBody + responses
  3. Beispiele und Fehlerfälle ergänzen

    03

    Konkrete Beispiele verhindern Missverständnisse und machen Integrationen schneller testbar.

    Erfolg + Validierungsfehler + fehlende Rechte + Konflikt
  4. Implementierung gegen den Vertrag prüfen

    04

    Automatisierte Tests oder Contract Checks erkennen Abweichungen zwischen Dokumentation und laufender API.

    Spec ↔ Server ↔ Test ↔ Client
  5. Ä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 Fortgeschrittene

Eine Spezifikation, viele Anwendungen

Die OpenAPI-Datei verbindet Design, Implementierung, Tests und Kommunikation über dieselbe Schnittstelle.

Wissenskarte

Maschinenlesbare Beschreibung von Endpunkten, Daten und Sicherheitsanforderungen.

Eine gut gepflegte Spezifikation macht Schnittstellen zu überprüfbaren und langfristig nutzbaren Produkten. OpenAPI-Spec gliedert sich in: API-Design, Dokumentation, Contract Tests, Client-SDK, Server-Validierung, Änderungslog.

01Einsatzbereiche

Wann ist OpenAPI / Swagger sinnvoll?

Geeignet für

  • API-DokumentationAutomatisch generierte, interaktive Docs für Entwickler
  • Code-GenerierungClient-SDKs und Server-Stubs aus der Spec generieren
  • API-TestingRequests direkt aus der Dokumentation testen
  • Contract-First DevelopmentErst API-Spec definieren, dann implementieren

↑ Inhalt

02Werkzeuge

Womit OpenAPI / Swagger umgesetzt wird

↑ Inhalt

Merksatz

OpenAPI ist wie ein Bauplan für APIs

Jeder Entwickler kann den Plan lesen und weiß genau, welche Endpunkte es gibt, welche Daten erwartet werden und was zurückkommt – ohne den Code zu lesen.

  1. Maschinenlesbares Format (YAML/JSON) zur API-Beschreibung
  2. Swagger UI generiert interaktive Dokumentation automatisch
  3. Ermöglicht Code-Generierung für Clients und Server

04Redaktion

Herkunft und Stand

Redaktion und Aktualität

Ebenex RedaktionRedaktion

Veröffentlicht
Aktualisiert

Dieses Feld entwickelt sich schnell. Oben stehen Veröffentlichung und letzte Änderung; ein Prüfdatum kommt dazu, sobald die Erklärung nach ihrer letzten Änderung geprüft wurde.

↑ Inhalt

05FAQ

Häufige Fragen zu OpenAPI / Swagger

Was ist der Unterschied zwischen OpenAPI und Swagger?

Swagger war der ursprüngliche Name. 2016 wurde die Spezifikation an die OpenAPI Initiative übergeben und heißt jetzt OpenAPI. Swagger bezeichnet heute die Tools (UI, Editor, Codegen).

OpenAPI 3.0 oder 3.1?

3.1 (aktuell) ist vollständig JSON-Schema-kompatibel. 3.0 hat noch kleine Abweichungen. Für neue Projekte 3.1 verwenden.

Wie halte ich die Spec aktuell?

Code-First: Spec aus Code generieren (Annotationen). Spec-First: Spec ist die Quelle, Code wird generiert oder validiert. Spec-First ist sauberer, Code-First praktischer.

Kann ich OpenAPI für GraphQL nutzen?

Nein, OpenAPI ist für REST. GraphQL hat eigene Introspection und Tools wie GraphiQL. Es gibt aber Tools, die beides unterstützen.

↑ Inhalt

06Weiterlernen

Was möchtest du als Nächstes verstehen?

↑ Inhalt