28 Implementierung von REST Controllern in Spring Boot

REST Controller in Spring Boot spielen eine zentrale Rolle bei der Entwicklung von RESTful Web Services. Sie agieren als Vermittler zwischen dem HTTP-Request des Clients und der Business-Logik der Anwendung. Spring Boot vereinfacht die Erstellung dieser Controller durch Annotationen wie @RestController und @RequestMapping.

28.1 Grundprinzipien

28.1.1 Trennung von Concerns

Es ist eine bewährte Praxis, keine umfangreiche Business-Logik direkt in den Controllern zu platzieren. Stattdessen sollten Controller Anfragen an Service-Klassen delegieren, die spezifisch für die Ausführung der Business-Logik zuständig sind. Diese Trennung sorgt für eine klare Architektur und erleichtert die Wartung und das Testing der Anwendung.

28.1.2 Verwendung von Service-Interfaces

Services sollten generell über Interfaces definiert werden. Dieser Ansatz fördert die Abstraktion und Entkopplung der Komponenten. Die Implementierung eines Service-Interfaces ermöglicht es, verschiedene Implementierungen des Services auszutauschen, ohne den REST Controller oder andere Teile der Anwendung zu ändern. Dies ist besonders nützlich in Szenarien, in denen verschiedene Verhaltensweisen oder Integrationen erforderlich sind, wie z.B. beim Wechsel der Datenquelle oder beim Mocking der Services für Tests.

28.1.3 Vorteile der Interface-Orientierung

• Abstraktion: Durch die Definition von Services als Interfaces wird die Abstraktionsebene erhöht, was die Entkopplung von Komponenten und die Flexibilität der Softwarearchitektur verbessert.
• Testbarkeit: Interfaces erleichtern das Erstellen von Mock-Implementierungen für Unit-Tests, da sie ohne eine konkrete Implementierung instanziiert werden können. Dies ist essenziell für das Testen von Controllern ohne Abhängigkeit auf die tatsächliche Business-Logik oder externe Ressourcen.
• Wartbarkeit und Erweiterbarkeit: Die Nutzung von Interfaces macht es einfacher, den Code zu warten und zu erweitern. Änderungen in der Implementierung eines Services haben keinen direkten Einfluss auf den Controller oder andere Teile der Anwendung, solange das Interface konstant bleibt.

28.2 Beispiel

@RestController
@RequestMapping("/api/resource")
public class ResourceController {

    private final ResourceService resourceService;

    @Autowired
    public ResourceController(ResourceService resourceService) {
        this.resourceService = resourceService;
    }

    @GetMapping("/{id}")
    public ResponseEntity<Resource> getResourceById(@PathVariable Long id) {
        Resource resource = resourceService.findById(id);
        return ResponseEntity.ok(resource);
    }
}

@Service
public class ResourceServiceImpl implements ResourceService {

    @Override
    public Resource findById(Long id) {
        // Implementierung der Logik, um die Ressource zu finden
    }
}

public interface ResourceService {
    Resource findById(Long id);
}

In diesem Beispiel delegiert der ResourceController Anfragen an den ResourceService, der durch ein Interface abstrahiert ist. Diese Struktur fördert sauberen, wartbaren und testbaren Code, indem sie die Business-Logik von den HTTP-Handling-Aufgaben trennt.