DocsPricingBlog
Contact Us
Log inSign up for FREE
Back to Tech Articles

Backend-APIs mit OpenAPI entwerfen und testen

Aug 30, 2025
# Misc

Grace Collins

Solutions Engineer · Leapcell

This post is also available in English, 日本語, and 한국어
Cover of "Backend-APIs mit OpenAPI entwerfen und testen"

Einleitung

In der sich schnell entwickelnden Landschaft der Softwareentwicklung sind APIs zum Fundament moderner Anwendungen geworden und ermöglichen eine nahtlose Kommunikation zwischen verschiedenen Systemen. Mit zunehmender Komplexität dieser Anwendungen werden die Verwaltung der API-Konsistenz, der Dokumentation und des Testens zu einer erheblichen Herausforderung. Herkömmliche Ansätze führen oft zu desynchronisierten Dokumentationen, mühsamen manuellen Tests und Kommunikationsabbrüchen zwischen Frontend- und Backend-Teams. Hier kommt die OpenAPI Specification, oft gleichbedeutend mit Swagger, als Game-Changer ins Spiel. Durch die Bereitstellung einer universellen, sprachunabhängigen Schnittstellenbeschreibung für REST-APIs ermöglicht OpenAPI Entwicklern, APIs mit beispielloser Klarheit und Effizienz zu definieren, zu entwerfen und zu nutzen. Dieser Artikel wird untersuchen, wie OpenAPI den Backend-API-Entwurfs- und Testprozess vorantreiben und ihn von einer reaktiven Pflicht zu einem proaktiven, integralen Bestandteil des Entwicklungslebenszyklus machen kann.

Kernkonzepte verstehen

Bevor wir uns mit den praktischen Aspekten befassen, wollen wir ein gemeinsames Verständnis der wichtigsten Begriffe im Zusammenhang mit OpenAPI schaffen.

  • API (Application Programming Interface): Ein Satz definierter Regeln, der es verschiedenen Anwendungen ermöglicht, miteinander zu kommunizieren. Für Backend-Zwecke konzentrieren wir uns hauptsächlich auf RESTful APIs, die Architekturbeschränkungen für vernetzte Anwendungen folgen und typischerweise HTTP-Methoden verwenden.
  • OpenAPI Specification (OAS): Eine standardisierte, sprachunabhängige Schnittstellenbeschreibung für RESTful APIs. Sie ermöglicht es sowohl Menschen als auch Computern, die Fähigkeiten eines Dienstes zu entdecken und zu verstehen, ohne Zugriff auf den Quellcode oder zusätzliche Dokumentation zu haben. Sie wird oft im YAML- oder JSON-Format verfasst.
  • Swagger: Historisch gesehen bezeichnete Swagger eine Reihe von Open-Source-Tools, die auf der OpenAPI Specification basieren, darunter Swagger UI (für interaktive API-Dokumentation), Swagger Editor (für die Gestaltung von APIs) und Swagger Codegen (für die Erzeugung von Server-Stubs und Client-SDKs). Obwohl "Swagger" immer noch häufig verwendet wird, um sich auf die Spezifikation selbst zu beziehen, wurde die Spezifikation an die Linux Foundation gespendet und in "OpenAPI Specification" umbenannt.
  • API-First Design: Ein Ansatz, bei dem die API vor ihrer Implementierung entworfen und spezifiziert wird. Dies steht im Gegensatz zu Code-First- oder Database-First-Ansätzen und fördert einen vertragsgesteuerten Entwicklungsprozess.
  • Server Stub: Eine grundlegende serverseitige Implementierung, die aus einer OpenAPI-Spezifikation generiert wird und Boilerplate-Code für API-Endpunkte bereitstellt, der dann mit der eigentlichen Geschäftslogik gefüllt werden kann.
  • Client SDK (Software Development Kit): Eine Code-Bibliothek, die aus einer OpenAPI-Spezifikation generiert wird und es Clients (z. B. Frontend-Anwendungen) ermöglicht, einfach mit der API zu interagieren, wobei die Details der HTTP-Anfragen abstrahiert werden.

Design mit OpenAPI vorantreiben

Das Grundprinzip der Verwendung von OpenAPI für das API-Design ist die API-First-Entwicklung. Anstatt Code zu schreiben und ihn dann zu dokumentieren, definieren wir zuerst den API-Vertrag mithilfe der OpenAPI Specification.

Prinzip: API-First-Entwicklung

Bei einem API-First-Ansatz wird das OpenAPI-Dokument zur einzigen "Source of Truth". Teams arbeiten an dieser Spezifikation zusammen und definieren:

  • Endpunkte und Pfade: Die URLs für den Zugriff auf verschiedene Ressourcen (z. B. /users, /products/{id}).
  • HTTP-Methoden: Die Aktionen, die an diesen Ressourcen durchgeführt werden können (z. B. GET, POST, PUT, DELETE).
  • Anforderungs-/Antwortschemata: Die Struktur und die Datentypen der an die API gesendeten und von ihr empfangenen Daten, die oft mithilfe von JSON Schema definiert werden.
  • Parameter: Eingaben, die für jeden Vorgang erforderlich sind (Pfad, Abfrage, Kopfzeile, Cookie).
  • Authentifizierungs- und Autorisierungsmethoden: Verwendete Sicherheitsmechanismen (z. B. API-Schlüssel, OAuth2).
  • Fehlerantworten: Standardisierte Fehlerformate für verschiedene Szenarien.

Implementierung: Design mit Swagger Editor

Tools wie der Swagger Editor ermöglichen es Entwicklern, OpenAPI-Spezifikationen interaktiv zu schreiben und bieten Echtzeitvalidierung und eine Vorschau der generierten Dokumentation.

Beispiel: Eine einfache User-API

Lassen Sie uns eine grundlegende API zur Verwaltung von Benutzern entwerfen:

# user-api.yaml
openapi: 3.0.0
info:
  title: User Management API
  version: 1.0.0
  description: API for managing user accounts.
servers:
  - url: http://localhost:8080/api/v1
    description: Local Development Server
paths:
  /users:
    get:
      summary: Retrieve a list of users
      operationId: listUsers
      parameters:
        - name: limit
          in: query
          description: How many items to return at one time (max 100)
          required: false
          schema:
            type: integer
            format: int32
      responses:
        '200':
          description: A paged array of users
          content:
            application/json:
              schema:
                type: array
                items:
                  $ref: '#/components/schemas/User'
        default:
          description: unexpected error
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/Error'
    post:
      summary: Create a new user
      operationId: createUser
      requestBody:
        required: true
        content:
          application/json:
            schema:
              $ref: '#/components/schemas/UserCreationRequest'
      responses:
        '201':
          description: User created successfully
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/User'
        default:
          description: unexpected error
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/Error'
  /users/{userId}:
    get:
      summary: Info for a specific user
      operationId: showUserById
      parameters:
        - name: userId
          in: path
          required: true
          description: The ID of the user to retrieve
          schema:
            type: string
      responses:
        '200':
          description: Expected response to a valid request
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/User'
        '404':
          description: User not found
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/Error'
        default:
          description: unexpected error
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/Error'
components:
  schemas:
    User:
      type: object
      required:
        - id
        - name
      properties:
        id:
          type: string
          format: uuid
          example: d290f1ee-6c54-4b01-90e6-d701748f0851
        name:
          type: string
          example: Alice
        email:
          type: string
          format: email
          example: alice@example.com
    UserCreationRequest:
      type: object
      required:
        - name
        - email
      properties:
        name:
          type: string
          example: Bob
        email:
          type: string
          format: email
          example: bob@example.com
    Error:
      type: object
      required:
        - code
        - message
      properties:
        code:
          type: integer
          format: int32
        message:
          type: string

Diese YAML-Datei definiert präzise die User-API. Frontend-Entwickler können sofort mit der Erstellung ihrer Benutzeroberfläche anhand dieses Vertrags beginnen und genau wissen, welche Anfragen sie senden und welche Antworten sie erwarten können. Backend-Entwickler können diese Spezifikation zur Steuerung ihrer Implementierung nutzen.

Anwendung: Code-Generierung

Sobald die OpenAPI-Spezifikation finalisiert ist, können Tools wie Swagger Codegen Server-Stubs und Client-SDKs generieren.

  • Backend (Server Stub Generation): Für Backend-Frameworks wie Spring Boot, Node.js (Express) oder Flask kann Codegen Controller-Schnittstellen, Modellklassen und sogar grundlegende Routing-Funktionen generieren. Entwickler füllen dann die Geschäftslogik innerhalb der generierten Struktur aus. Dies stellt sicher, dass die Implementierung strikt an die definierte API-Vertrags gehalten wird.

    # Beispiel mit openapi-generator-cli für einen Spring Boot Server Stub
npx @openapitools/openapi-generator-cli generate \
  -i user-api.yaml \
  -g spring \
  -o ./generated-server \
  --additional-properties packageName=com.example.userapi

    Dieser Befehl würde ein Spring Boot-Projekt mit UserController-Schnittstellen, User-Modellklassen usw. erzeugen, die zur Implementierung bereit sind.

  • Frontend (Client SDK Generation): Für Frontend-Frameworks wie React, Angular oder sogar mobile Apps kann Codegen clientseitige Bibliotheken generieren, die API-Aufrufe kapseln. Dies eliminiert die manuelle Erstellung und Verarbeitung von HTTP-Anfragen und reduziert Fehler sowie spart Entwicklungszeit.

    # Beispiel mit openapi-generator-cli für einen TypeScript-Client
npx @openapitools/openapi-generator-cli generate \
  -i user-api.yaml \
  -g typescript-axios \
  -o ./generated-client

    Dies generiert einen TypeScript-Client, den Frontend-Entwickler importieren und verwenden können: api.user.listUsers({limit: 10}).

Design mit OpenAPI testen

OpenAPI-Spezifikationen sind nicht nur zur Dokumentation und zum Design da; sie sind wertvolle Ressourcen zur Automatisierung von API-Tests.

Prinzip: Contract Testing und automatisierte Validierung

Das OpenAPI-Dokument dient als Test-Orakel. Jede API-Implementierung sollte diesem Vertrag entsprechen. Dies ermöglicht:

  1. Schema-Validierung: Sicherstellen, dass Anforderungs- und Antwortkörper den definierten JSON-Schemas entsprechen.
  2. Endpoint-Abdeckung: Überprüfung, ob alle definierten Endpunkte korrekt antworten.
  3. Verhaltensbezogenes Testen: Erstellung von Testfällen, die verschiedene Szenarien abdecken, einschließlich gültiger Eingaben, Randfälle und Fehlerbedingungen, alles basierend auf der Spezifikation.

Implementierung: Testen mit spezialisierten Tools

Mehrere Tools nutzen OpenAPI für automatisiertes Testen.

  • Postman/Insomnia: Diese beliebten API-Clients können OpenAPI-Spezifikationen importieren, um Anforderungssammlungen zu generieren, was das manuelle und automatisierte Testen erheblich erleichtert. Sie können dann Assertionen hinzufügen, um Antworten gegen das Schema zu validieren.

  • Dredd (für Node.js) / Schemathesis (für Python): Diese Tools lesen direkt eine OpenAPI-Spezifikation und testen die API-Implementierung dagegen. Sie können Testfälle basierend auf den Schema-Definitionen automatisch generieren und die Antworten validieren.

    Beispiel: Testen mit Schemathesis (Python Backend)

    Angenommen, unsere User-API ist in Python mit Flask implementiert.

    # app.py (minimales Flask App Beispiel)
from flask import Flask, jsonify, request
import uuid

app = Flask(__name__)

users_db = {} # In-Memory-Speicher 

@app.route('/api/v1/users', methods=['GET'])
def list_users():
    limit = request.args.get('limit', type=int, default=100)
    return jsonify(list(users_db.values())[:limit])

@app.route('/api/v1/users', methods=['POST'])
def create_user():
    data = request.json
    if not data or 'name' not in data or 'email' not in data:
        return jsonify({"code": 400, "message": "Missing name or email"}), 400
    
    new_user = {
        "id": str(uuid.uuid4()),
        "name": data['name'],
        "email": data['email']
    }
    users_db[new_user['id']] = new_user
    return jsonify(new_user), 201

@app.route('/api/v1/users/<user_id>', methods=['GET'])
def show_user_by_id(user_id):
    user = users_db.get(user_id)
    if user:
        return jsonify(user), 200
    return jsonify({"code": 404, "message": "User not found"}), 404

if __name__ == '__main__':
    app.run(debug=True, port=8080)

    Um diese Flask-Anwendung mit schemathesis zu testen:

    # Installieren Sie zuerst schemathesis
pip install schemathesis flask gunicorn

# Speichern Sie Ihre Flask-App als app.py und führen Sie sie aus
gunicorn -b 127.0.0.1:8080 app:app & 

# Führen Sie dann schemathesis gegen Ihre laufende API und die OpenAPI-Spezifikation aus
schemathesis run -H "Accept: application/json" --base-url="http://127.0.0.1:8080/api/v1" user-api.yaml

    schemathesis sendet Tausende von Anfragen, um Schemaverletzungen, unbehandelte Fehler und andere API-Inkonsistenzen zu finden. Es generiert automatisch diverse Eingabewerte, um Ihre API gemäß dem in user-api.yaml definierten Typ und Format zu stress-testen.

  • Spezifische Framework-Integrationen: Viele Backend-Frameworks bieten Integrationen. Zum Beispiel kann in Spring Boot springdoc-openapi ein openapi.json aus Ihren Annotationen generieren, und dann können Sie Tools wie REST Assured mit Schema-Validierung verwenden. Alternativ können für Frameworks, die Code-Generierung unterstützen, die generierten DTOs direkt in Unit- und Integrationstests verwendet werden, um Typsicherheit und Konformität der Serialisierung sicherzustellen.

Anwendung: Continuous Integration und Delivery (CI/CD)

Die Integration von OpenAPI-gesteuerten Tests in CI/CD-Pipelines stellt sicher, dass jede Codeänderung anhand des API-Vertrags validiert wird.

  • Pre-commit Hooks/Pre-push Hooks: Validieren der OpenAPI-Spezifikation selbst auf syntaktische Korrektheit und Best Practices.
  • Build-Pipeline: Automatisches Generieren von Client-SDKs und Server-Stubs. Ausführen automatisierter Contract-Tests (schemathesis, Dredd) gegen eine bereitgestellte (oder Mock-) Version der API.
  • Deployment-Gate: Den Build fehlschlagen lassen, wenn Contract-Tests fehlschlagen, und so verhindern, dass nicht-konforme APIs bereitgestellt werden.

Diese robuste Testmethodik fängt Breaking Changes frühzeitig ab, erzwingt Konsistenz und reduziert das Risiko von Integrationsproblemen für API-Konsumenten erheblich.

Fazit

Die OpenAPI Specification verwandelt die API-Entwicklung von einer Reihe Ad-hoc-Aufgaben in einen strukturierten, vertragsgesteuerten Prozess. Durch die Nutzung zur Steuerung des Designs etablieren wir eine einzige "Source of Truth", die parallele Entwicklung, optimierte Kommunikation und schnelles Prototyping durch Code-Generierung ermöglicht. Darüber hinaus ermöglicht die Integration von OpenAPI in die Testphase Entwicklern die Automatisierung der Vertragsvalidierung und umfassender Verhaltensprüfungen, um die API-Qualität und die Einhaltung definierter Standards sicherzustellen. Die Übernahme eines OpenAPI-First-Ansatzes verbessert die Zusammenarbeit, Effizienz und Zuverlässigkeit über den gesamten API-Lebenszyklus hinweg erheblich. Im Wesentlichen schlägt OpenAPI die Brücke zwischen Design und Implementierung und ermöglicht Entwicklern, robuste, wartbare und gut dokumentierte APIs mit Zuversicht zu erstellen.

Share this article

HackerNews

More Posts from Leapcell

Popular Posts