© Excellent backgrounds/Shutterstock.com
Java Magazin
Kolumne: EnterpriseTales

Kolumne: EnterpriseTales


Nicht selten ist die Weiterentwicklung von APIs eine so große Herausforderung für Entwickler, dass sie versuchen, ganz darauf zu verzichten und ein einmal veröffentlichtes API möglichst stabil zu halten. Das ist grundsätzlich zunächst keine schlechte Idee. Allerdings führen neue Anforderungen und die damit verbundene Weiterentwicklung der Implementierung schnell dazu, dass API und Businesslogik auseinanderlaufen.

Im besten Fall führt das Auseinanderlaufen zu einer schlecht wartbaren Mapping-Schicht zwischen dem Code, der das API zur Verfügung stellt, und der Implementierung der Businesslogik. Im schlimmsten Fall führt es dazu, dass in der Schnittstelle Felder semantisch umdefiniert werden, um neuen Anforderungen zu genügen und dabei die Schnittstelle aber syntaktisch stabil zu halten. Eine solche implizite Weiterentwicklung des API führt zunächst scheinbar dazu, dass sich die Schnittstelle nicht ändert. Tatsächlich aber ist die semantische Umdefinition von Feldern sehr wohl eine Schnittstellenänderung, die dazu führt, dass alle Clients nachgezogen werden müssen. Was die ganze Situation noch viel schlimmer macht, ist, dass eventuell existierende Clients die semantische Änderung nicht einmal bemerken und so auf Basis von falschen Annahmen weiterarbeiten.

Weiterentwicklung oder stabiles API

Das Ansinnen, das API stabil zu halten, steht natürlich im direkten Widerspruch zu der Tatsache, dass sich Code ständig ändert. Wie bereits erwähnt, wird diesem Phänomen häufig mit dem architektonischen Pattern begegnet, eine Mapping-Schicht zwischen Businesslogik und Schnittstellencode einzuziehen. Die Objekte, die in dieser Mapping-Schicht verwendet werden, werden häufig Schnittstellenmodell oder DTOs (Data Transfer Objects) genannt. Je länger ein API existiert, ohne dass es weiterentwickelt wird, umso komplexer wird in der Regel diese Mapping-Schicht. Oft gibt es niemanden, der sich so richtig in der Mapping-Schicht auskennt. Das führt dazu, dass jede Änderung in der Mapping-Schicht nur mit hohem Entwicklungsaufwand zu realisieren ist. Häufig, weil die Mapping-Schicht mit einem alten, selbstgeschriebenen Mapping-Framework realisiert ist. Alternativ kommen auch existierende Mapping-Frameworks wie Dozer [1] vor, dann aber mit einer komplizierten Konfiguration.

Bei einer weiteren Variante – und die kann sich für Unternehmen als noch schlimmer herausstellen – gibt es genau einen Experten für die Mapping-Schicht, der das Mapping schon immer gemacht hat und auch für immer ma...

Java Magazin
Kolumne: EnterpriseTales

Kolumne: EnterpriseTales

Nicht selten ist die Weiterentwicklung von APIs eine so große Herausforderung für Entwickler, dass sie versuchen, ganz darauf zu verzichten und ein einmal veröffentlichtes API möglichst stabil zu halten. Das ist grundsätzlich zunächst keine schlechte Idee. Allerdings führen neue Anforderungen und die damit verbundene Weiterentwicklung der Implementierung schnell dazu, dass API und Businesslogik auseinanderlaufen.

Arne Limburg


Nicht selten ist die Weiterentwicklung von APIs eine so große Herausforderung für Entwickler, dass sie versuchen, ganz darauf zu verzichten und ein einmal veröffentlichtes API möglichst stabil zu halten. Das ist grundsätzlich zunächst keine schlechte Idee. Allerdings führen neue Anforderungen und die damit verbundene Weiterentwicklung der Implementierung schnell dazu, dass API und Businesslogik auseinanderlaufen.

Im besten Fall führt das Auseinanderlaufen zu einer schlecht wartbaren Mapping-Schicht zwischen dem Code, der das API zur Verfügung stellt, und der Implementierung der Businesslogik. Im schlimmsten Fall führt es dazu, dass in der Schnittstelle Felder semantisch umdefiniert werden, um neuen Anforderungen zu genügen und dabei die Schnittstelle aber syntaktisch stabil zu halten. Eine solche implizite Weiterentwicklung des API führt zunächst scheinbar dazu, dass sich die Schnittstelle nicht ändert. Tatsächlich aber ist die semantische Umdefinition von Feldern sehr wohl eine Schnittstellenänderung, die dazu führt, dass alle Clients nachgezogen werden müssen. Was die ganze Situation noch viel schlimmer macht, ist, dass eventuell existierende Clients die semantische Änderung nicht einmal bemerken und so auf Basis von falschen Annahmen weiterarbeiten.

Weiterentwicklung oder stabiles API

Das Ansinnen, das API stabil zu halten, steht natürlich im direkten Widerspruch zu der Tatsache, dass sich Code ständig ändert. Wie bereits erwähnt, wird diesem Phänomen häufig mit dem architektonischen Pattern begegnet, eine Mapping-Schicht zwischen Businesslogik und Schnittstellencode einzuziehen. Die Objekte, die in dieser Mapping-Schicht verwendet werden, werden häufig Schnittstellenmodell oder DTOs (Data Transfer Objects) genannt. Je länger ein API existiert, ohne dass es weiterentwickelt wird, umso komplexer wird in der Regel diese Mapping-Schicht. Oft gibt es niemanden, der sich so richtig in der Mapping-Schicht auskennt. Das führt dazu, dass jede Änderung in der Mapping-Schicht nur mit hohem Entwicklungsaufwand zu realisieren ist. Häufig, weil die Mapping-Schicht mit einem alten, selbstgeschriebenen Mapping-Framework realisiert ist. Alternativ kommen auch existierende Mapping-Frameworks wie Dozer [1] vor, dann aber mit einer komplizierten Konfiguration.

Bei einer weiteren Variante – und die kann sich für Unternehmen als noch schlimmer herausstellen – gibt es genau einen Experten für die Mapping-Schicht, der das Mapping schon immer gemacht hat und auch für immer ma...

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang