← Zurück

Design Patterns in REST API Design

Pattern Zweck Einsatzort Begründung
DTO API-Vertrag vom Domain Model trennen CreateOrderRequest, OrderResponse REST-API bleibt stabil, Domain kann sich unabhängig entwickeln.
Mapper DTO und Domain bewusst übersetzen OrderMapper Verhindert Entity-Leaks und zentrale Konvertierungslogik.
Controller / Primary Adapter HTTP in Use Cases übersetzen RestOrderController Der Domain-Kern kennt keine HTTP-Header, Statuscodes oder JSON.
Application Service Use Case orchestrieren OrderApplicationService Transaktions-/Use-Case-Grenze ist sichtbar und testbar.
Repository Speicherzugriff kapseln OrderRepository Application Code hängt nicht am Speichermechanismus.
Adapter Technische Details implementieren Ports InMemoryOrderRepository Austausch gegen JPA/JDBC/REST ist möglich.
Factory Konsistente Fehlerobjekte erzeugen ProblemDetailsFactory Problem Details bleiben einheitlich und maschinenlesbar.
Idempotency Store Doppelte POSTs kontrollieren IdempotencyStore Verhindert doppelte fachliche Wirkung bei Retry/Timeout.
Optimistic Offline Lock Verlorene Updates verhindern ETag, If-Match API-Konflikte werden explizit und fachlich behandelbar.
⌂ Cockpit