Gedanken zur agilen Softwareentwicklung
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.
Nachdem im vorherigen Beitrag zum Thema, die Prüfung der deutschen IBAN und BIC verbessert wurde, rundet dieser Beitrag die Validierung ab.
Im ersten Teil zu der IBAN und BIC Validierung wurden erste Implementierungen vorgestellt um die syntaktische Korrektheit von IBAN und BIC zu prüfen und bei der IBAN zusätzlich die Prüfsumme zu nutzen. In diesem Beitrag sollen zusätzliche landesspezifische Eigenschaften genutzt werden. Insbesondere die Informationen der Deutschen Bundesbank zu den deutschen Geldinstituten.
Nach den Beiträgen zu der eher unbekannten Leitweg-ID und den geläufigen Telefonnummern wird sich dieser Beitrag mit den beiden bekanntesten IDs aus dem Zahlungswesen beschäftigen, der IBAN und dem BIC.
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.
Bei der Erstellung eigner Stammbäume gibt es immer wieder den Wunsch in anderen Datenbeständen nach Familienangehörigen zu suchen. Dabei ergibt sich jedoch das Problem, dann personenbezogene Daten an andere versendet werden müssen.
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.
Im letzten Beitrag wurde ein erster Bot für Mastodon erstellt. Der Bot postet mittlerweile drei mal täglich um 8:00, 12:00 und 16:00 Uhr ein englischsprachiges Zitat auf Mastodon. Obwohl die Anwendung schon hinreichend arbeitet, fehlen noch Kleinigkeiten zum dauerhaften Einsatz.