Spring Data REST, OpenAPI und Contract-Grenzen
Spring Data REST kann Repositorys direkt als hypermedia-getriebene HTTP-Ressourcen exponieren; OpenAPI/springdoc ergänzt maschinenlesbare REST-Beschreibungen.
Fachliche Einordnung
Direkt exponierte Repositorys sind schnell, aber riskant. Enterprise-APIs brauchen fachliche Grenzen, Versionsstrategie und Security. Daher ist Spring Data REST eher für interne, bewusst begrenzte Ressourcen geeignet.
Technische Darstellung
Kernkonzepte
- Repository Exposure als REST Resources.
- HAL und Hypermedia.
- Projections und Excerpts.
- OpenAPI für Client- und Vertragssicht.
- Consumer Driven Contracts als zusätzliche Absicherung.
Wann einsetzen?
- Du brauchst schnell interne Admin-/Backoffice-Ressourcen.
- Du möchtest Hypermedia über Repositorys demonstrieren.
- Du kombinierst Dokumentation mit Contract Tests.
Typische Fehler und Risiken
- Repositorys unkontrolliert öffentlich freigeben.
- Fachliche Use Cases umgehen.
- OpenAPI als Ersatz für Architekturentscheidungen missverstehen.
Legacy- und Modernisierungssicht
Für Legacy-Admin-Oberflächen kann ein begrenztes internes Data-REST-API als Übergang helfen, sollte aber nicht zur Hauptdomänenschnittstelle werden.
Ausführliches Beispiel
Das Beispiel zeigt bewusst nicht nur Annotationen, sondern auch die Verantwortung der Schicht. In echten Projekten sollte der technische Spring-Code an Adapter- oder Konfigurationsrändern bleiben, während die Fachlogik testbar und möglichst frameworkarm bleibt.
@RepositoryRestResource(path = "internal-products")
interface ProductAdminRepository extends PagingAndSortingRepository<ProductEntity, UUID> {
@RestResource(path = "by-sku")
Optional<ProductEntity> findBySku(@Param("sku") String sku);
}
@Configuration
class RepositoryRestSecurityNote {
// Wichtig: für öffentliche APIs meist lieber Controller + Use Case + DTO verwenden.
}
Checkliste für Reviews
- Ist die Verantwortung des Bausteins klar: Framework steuert Lebenszyklus, Library wird gezielt benutzt?
- Ist die Fachlogik außerhalb von Controller, Listener, Repository-Implementierung oder Konfiguration?
- Sind Fehlerfälle, Timeouts, Security, Monitoring und Tests sichtbar modelliert?
- Gibt es klare Grenzen zwischen DTO, Domäne, Persistence und Infrastruktur?