Records on the rise – Goodbye Lombok
Since the introduction of Java Records in Java 14 (JEP 359), their support in many frameworks has continued to grow. Support is now so great that we should consider banning Lombok from all our projects.
Thoughts on agile software development
Since the introduction of Java Records in Java 14 (JEP 359), their support in many frameworks has continued to grow. Support is now so great that we should consider banning Lombok from all our projects.
This article is a slightly updated English version of the article “REST Endpunkte mit Filtern”.
In addition to sorting and pagination, filtering is a fairly common action on REST endpoints. In contrast to the first two, however, there is no adequate solution for filtering in the Spring Boot framework. With little effort, however, this can be elegantly implemented with the Spring Boot tools.
Spring Boot endpoints can be formulated briefly and concisely. Their return values are automatically converted into suitable responses. Occasionally, the developer has to fall back on the ResponseEntity class as a return value. This is the case, for example, when additional HTTP headers are required, such as the Cache-Control header.
Spring Boot has an excellent error mechanism for REST endpoints. A @RestontrollerAdvice provides handling methods for various types of exception that can occur when processing REST requests. If you are not careful here, you can end up with an unsightly spread of different error message formats.
In diesem Beitrag geht es um eine weitere Ergänzung im kleinen Zoo der Validatoren der Telephone Bibliothek. Bislang existierten Validatoren für die Länderkennzahl und die deutschen Mobilvorwahlen, es fehlte die Validierung der deutschen Ortsnetzkennzahlen. Die Validierung der deutschen Ortsnetzkennzahlen fehlte bislang in der Bibliothek, weil es insgesamt 5200 von ihnen gibt. Dis bisher existierende Validierung für Mobilvorwahlen kümmerte sich nur um 54 Vorwahlen, die mit Hilfe einer einfachen Platzhaltersyntax auf 10 Vergleichswerte reduziert wurden.
Bei der Weiterentwicklung einer REST API kommt es hin und wieder zu veränderten Darstellungen der Attribute. Je nachdem wie der Versionierung der eigenen API gestaltet wurden, ergeben sich eine Reihe von Möglichkeiten mit geänderten Attributen umzugehen.
Im ersten Teil des Beitrags wurde gezeigt, wie man die Klasse InternationalPhoneNumber aus dem Telephone Projekt mit der Jackson Bibliothek verwenden kann. Im zweiten Teil soll die erste Implementierung noch etwas anwendungsfreundlicher werden.
Im letzten Beitrag wurde für die Klasse InternationalTelephoneNumber aus dem Projekt Telephone ein Serialisierer und ein Deserialisierer für Jackson erstellt. Damit ist es möglich diese Klasse direkt in REST Request einzusetzen. Zusätzlich wäre eine Validierung der Telefonnummern wünschenswert. Auf diese Weise könnten Telefonnummern mit speziellen Vorwahlen oder Durchwahlen abgelehnt werden.
Immer wieder kommt es vor, dass man im eigenen Spring Boot REST-Controller Klassen verwenden möchte, die nicht dafür konstruiert wurden. In der Regel trifft dies auf Klassen zu, die aus Dritt-Bibliotheken stammen.
Das Logging von Web-Anwendungen, bzw. allen Server-Anwendungen ist mit seinen eigenen kleinen Tücken versehen. Die üblichen, mehr oder wenig hilfreichen Log Anweisungen, die sich im Source Code tummeln, sorgen für einen stetigen Strom von Log-Ausgaben. Solange sich die Ausgabe auf einen einzelnen Request bezieht, ist häufig noch sehr gut nachvollziehbar, was gerade auf dem Server passiert. Bei sehr vielen Anfragen an den Server leidet aber die Übersicht.