Thoughts on agile software development
Some features of a framework are so expected that you end up being surprised when they don’t actually exist. Just recently, it happened again: our team thought it would be better to write a Spring Data construct using a query method. But at first, it didn’t work.
API versioning is essential for the ongoing development of REST APIs without breaking changes. Spring Boot 4 introduces new features in this area. This article presents the common versioning strategies (URL-based, header-based, and others) and explains the new features in Spring Boot 4.
Spring Modulith is now available in version 1.3.0. So it’s time to write an article about this framework. I have created many microservices with Spring Boot over the last few years, but of course that doesn’t mean that you can’t also create large, monolithic applications with the framework.
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.