Thoughts on agile software development
Der Bean Validation 2.0 (JSR380) Framework nimmt dem Java Entwickler viel Arbeit ab. Die Prüfung auf valide Daten reduziert sich mittlerweile auf einige Annotationen an den zu prüfenden Konstrukten. Auch im Bereich der Datumsprüfungen gibt es reichlich Unterstützung. Aber manchmal kann es ein wenig mehr sein.
Mit Spring Boot können eigene REST Services schnell erstellt werden. Die dabei notwendige Validierung der Parameter ist mit dem Bean Validation Framework (JSR 380) auch in Windeseile hinzugefügt. Manchmal ist es aber notwendig verschiedene Parameter gegeneinander zu prüfen, dann reichen die Standardwerkzeuge nicht mehr aus und eigene Validatoren müssen erstellt werden. Anhand eines kleines Beispiel zeigt dieser Beitrag, wie einfach das geht.
Der Spring Boot WebClient ist der reaktive, nicht blockierende Alternative zum RestTemplate. Obwohl der WebClient für die Anwendung in reaktiven Anwendungen entworfen wurde, kann er auch in klassischen Anwendungen das RestTemplate ersetzen. Insbesondere die moderne Implementierung und die Fluent API sind es, die den Software Entwickler die Entscheidung für den WebClient leicht machen. Obwohl die Fluent API des WebClient ein Segen für die Entwicklung ist, stellt sie einen Fluch für die Unit Tests da.
Die Bibliothek SpringDoc-OpenAPI ist ein gute Ergänzung für die eigene REST API, um die Endpunkte mit einer Dokumentation zu versehen. Die Bibliothek analysiert die @RestController annotierten Klassen und extrahiert Informationen zu Endpunkten, Parametern, Requests, Responses und Fehlercodes. Die gefundenen Informationen werden als OpenAPI Dokumentation im YAML oder JSON Format ausgegeben. Das klingt sehr gut, nur leider funktioniert es nicht ohne zusätzliche Eingriffe der Entwickler.
REST Services können nur eine gewisse Anzahl von Anfragen innerhalb eines Zeit Fensters verarbeiten. Werden zu viele Anfragen gestellt, dann gerät der Service unter Last und reagiert sehr langsam oder gar nicht mehr. Zusätzliche Anfragen, die ein vorgegebenes Limit übersteigen, sollten daher vom Service abgelehnt werden.
Bei der Verwendung von REST Schnittstellen beginnt die Evolution eigener APIs mit der Erstellung einiger HTTP Endpunkte die Informationen im JSON Format austauschen. Die nächste Stufe ist die Abkehr von der Denkweise in Aktionen hin zum Verständnis, dass über REST Resourcen addressiert und manipuliert werden.
Wenn mehr als ein Beteiligter beim Speichern von Daten involviert ist, kann es zu ungewollten Überschreibungen kommen. Um solche Probleme zu umgehen, existieren drei Vorgehensweisen. Pessimistic Locking, Optimistic Locking und Ignore It!
Hin und wieder schleichen sich I18N Anforderungen in die eigenen Anwendungen ein, die als einsprachige Anwendung gestartet wurde. Der offensichtlichste Fall für solch eine Mehrsprachigkeit ist z.B. eine Serviceseite im Kita Bereich. Da häufig Kinder verschiedenster Nationalitäten eine Kita besuchen, sind Informationen in der Muttersprache der Eltern hilfreich.
Im Zuge der Implementierung einer Restschnitstelle für die Verwaltung von Ahnenfoschungsvereinen kam die Frage auf, ob man die Datenbankabfragen nicht cachen könnte. Da der Bestand an solchen Vereinen sich selten verändert, liefert dieser Mikroservice fast immer identische Ergebnisse.
Die Entwicklung von Rest Schnittstellen mit Spring Boot wird durch viele Features des Frameworks begünstigt. Insbesondere durch die einfache Umsetzung der Rest Controller mit Hilfe einer Vielzahl von Annotationen und die Persistenz mit Spring Data JPA.
Während die Persistenzschicht mit ihren Repositories auf Entity Klassen arbeitet, werden vom Rest Controller DTOs verwenden. Entities und DTO arbeiten auf der Grundlagen identischer Domänenobjekte, unterscheiden sich aber zwangsläufig durch ihre sehr unterschiedliche Nutzung. So besitzen Entities häufig Attribute zur Speicherung des Änderungsdatums und eines eindeutigen Datenbankschlüssels.