Thoughts on agile software development
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.
Many interesting libraries are created through the Java Specification Requests process. Many of them are incorporated directly into the JDK, but some exist as independent libraries. Some time ago I wrote about the Moneta library. This article is about a Jackson use case for Indriya, the JSR 385 (Units of Measurement API) reference implementation.
Anyone who has ever worked with Web APIs, and who hasn’t, will be aware of the difficulties of testing in an API environment. When testing an API, there are two sides to consider, that of the producer and that of the consumer. If both do not work hand in hand, then problems are inevitable. Consumer contract tests are designed to avoid some of the difficulties in API testing.
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.
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.