Das Mysterium um die Zukunft von Springs RestTemplate begann damit, dass das Spring-Projekt in Version 5 ankündigte, dass das RestTemplate zukünftig als deprecated betrachtet wird. Seit der Verbreitung dieser Nachricht geht in vielen Entwicklungsabteilungen die Sorge um, dass alle Aufrufe des RestTemplates ersetzt werden müssen - und teilweise auch konkrete Tickets zur Änderung. In diesem Beitrag gehen wir der Frage nach, was es mit dieser Ankündigung auf sich hat(te), was für Optionen Entwicklungsabteilungen haben, auf die Ankündigung zu reagieren – und ob sie es überhaupt müssen.

Akt 1: Die Ankündigung

Die Verwirrung und Unsicherheit um die Zukunft des RestTemplates begann damit, dass in der Dokumentation von Spring 5 für einige Zeit, um genau zu sein seit dem Release von Spring 5.0.9 vom 7.9.2018 - folgende Notiz in der Dokumentation zur Klasse RestTemplate zu lesen war:

NOTE: As of 5.0, the non-blocking, reactive org.springframework.web.reactive.client.WebClient offers a modern alternative to the RestTemplate with efficient support for both sync and async, as well as streaming scenarios. The RestTemplate will be deprecated in a future version and will not have major new features added going forward.

Diese Notiz ist erstmal unmissverständlich - das RestTemplate, Springs Implementierung für synchrone HTTP-Kommunikation, wird zu den Akten gelegt. Bitte alle den WebClient samt WebFlux-Dependency nutzen. So weit, so viel Migrationsaufwand… oder?

Nun existiert schon seit Java 1.5, also auch in jedem Projekt, das Spring 5.x einsetzt, die viel genutzte @Deprecated-Annotation im package java.lang, mit der Klassen als veraltet und nicht mehr zu nutzen markiert werden. Moderne IDEs zeigen dies auch bei Verwendung an. Auch das generierte Javadoc bietet eine Liste aller Deprecated Classes.

Die RestTemplate-Klasse hat diese Annotation jedoch nie erhalten. Eine Deprecation ohne diese Annotation entspricht so auch nicht dem Prozess des Spring-Projekts, das normalerweise auch einen guten Ruf für die frühe Ankündigung solcher Änderungen hat. Bei einem Projekt dieser Größenordnung ist es problematisch, Funktionalität ohne klaren Migrationspfad als veraltet zu kennzeichnen. Eine bloße Notiz in der Dokumentation reicht nicht aus - ein solches Vorgehen würde die Community zu stark verärgern. Also… vielleicht erstmal abwarten und Tee trinken?

Akt 2: Der Rücktritt vom Rücktritt

Mit dem Release von Spring 5.2.4 vom 25.2.2020, also knapp anderthalb Jahre später, wurde auch die Dokumentation der RestTemplate-Klasse aktualisiert. Nun las sich die entsprechende Notiz anders:

NOTE: As of 5.0 this class is in maintenance mode, with only minor requests for changes and bugs to be accepted going forward. Please, consider using the org.springframework.web.reactive.client.WebClient which has a more modern API and supports sync, async, and streaming scenarios.

Kein Wort mehr von “deprecated”, stattdessen wird hier erklärt, dass das RestTemplate im maintenance mode weiterlebt - also quasi feature-complete ist. Wer schon einmal mit dem RestTemplate gearbeitet hat, weiß, dass man das durchaus so sehen kann. Das RestTemplate wird so seit Spring 3 als Client genutzt.

Also: Alarme aus, Tickets wieder ins Backlog! Das RestTemplate kann zwar als feature-complete angesehen werden, nicht aber als deprecated. Tja, dann… alles gut? Es scheint so, aber nun ist auch Spring 5 schon sehr bald am Ende seines Lebenszyklus angekommen - wie sieht es also mit der Unterstützung des RestTemplates in Spring 6 und der weiteren Zukunft aus?

Akt 3: Der neue, alte Bekannte

Zuerst die hoffentlich gute Nachricht: Das RestTemplate ist auch mit Spring 6 nicht als deprecated markiert worden. Stattdessen wurden in Version 6.1.0 sogar weitere Änderungen an der Dokumentation gemacht, um noch mehr Klarheit zu schaffen:

NOTE: As of 6.1, RestClient offers a more modern API for synchronous HTTP access. For asynchronous and streaming scenarios, consider the reactive org.springframework.web.reactive.function.client.WebClient.

RestTemplate and RestClient share the same infrastructure (i.e. request factories, request interceptors and initializers, message converters, etc.), so any improvements made therein are shared as well. However, RestClient is the focus for new higher-level features.

Das RestTemplate ist jetzt also weder deprecated, noch im maintenance mode. Es dient im Gegenteil im Hintergrund als Infrastruktur für den neuen, modernen RestClient mit fluid API, und wird so auch weiterentwickelt, auch wenn einige Features dem neuen RestClient vorbehalten bleiben. Nun haben wir also drei Clients zur Auswahl: RestTemplate, WebClient und RestClient. Wer die Wahl hat, hat die Qual, nicht wahr? Vielleicht hilft dieser kleine Überblick:

Wenn Sie heute ein neues Projekt anlegen, sind für das reaktive Modell der WebClient oder bei Nutzung des imperativen Programmiermodells der Rest-Client (ab Spring 6.1) als moderne Alternative zum RestTemplate verfügbar.

Die Entscheidung, welcher der drei Clients verwendet werden soll, können Sie mit der Entscheidung verknüpfen, welches Programmiermodell genutzt wird, bzw. genutzt werden soll: Wird reaktive Programmierung verwendet, oder mit dem imperativen Modell entwickelt?

Nutzen Sie jetzt also gar keine reaktiven Konzepte in der Anwendung, “gewinnen” Sie durch die Nutzung des WebClients nur eine weitere Abhängigkeit, die maintained (aktualisiert, gepflegt) werden muss. Die Einbindung von Spring WebFlux birgt ein Risiko, da reaktive Konzepte in nicht-reaktiven Code “durchsickern” könnten. Obwohl diese Vermischung der Konzepte auf den ersten Blick vielversprechend erscheinen mag, führt sie in der Regel nicht zu einer Verbesserung der Performance. Der Grund dafür ist, dass reaktive Codeteile erfahrungsgemäß intern oft wieder auf synchrone Verarbeitung zurückgreifen.

Besonders problematisch ist zudem, dass eine solche Vermischung den Code schwer les- und verstehbar machen kann, was die Wartbarkeit und Weiterentwicklung der Anwendung erheblich erschwert.

Eine genauere Gegenüberstellung der reaktiven und imperativen Paradigmen ist nicht Teil dieses Beitrags. Für eine angemessene Nutzung reicht es, wenn Sie sich merken, nicht beide Konzepte zu vermischen und sich für die im eigenen Kontext passende Lösung entscheiden.

Ist die Anwendung also nicht reaktiv, bleiben RestClient oder RestTemplate übrig. Hier spielt in bestehenden Projekten der Migrationsaufwand wohl eine große Rolle. Brauchen Sie die neuen “higher-level features” und die neue fluid API nicht, ist es eine Kosten-Nutzen-Abwägung, ob sich der Migrationsaufwand hier lohnt.

Für Neuentwicklungen empfiehlt es sich, damit aktuelle und zukünftige “higher-level features” sicher genutzt werden können, zuerst einen Blick auf den RestClient zu werfen. Dieser wartet schon jetzt mit einem durchdachten, einfacher nutzbaren API auf. Beachten Sie aber, dass der RestClient im Gegensatz zum RestTemplate noch relativ neu ist und so vielleicht noch ein paar Kinderkrankheiten zu durchleben hat. Soll Ihr RestClient zum Beispiel als ausgehender Client OAuth2 nutzen, so ist dieses Feature zur Veröffentlichungszeit dieses Beitrages noch nicht integriert - es ist jedoch für Spring 6.4 in Arbeit.

Das RestTemplate ist dagegen feature-complete, quasi “gut abgehangene” Software, die für eine synchrone Kommunikation einwandfrei geeignet ist. Und, vor allem, ist es nicht deprecated.

Fazit

Wir hoffen, das Mysterium um die Zukunft von Springs RestTemplate mit diesem Artikel aufgeklärt zu haben. Durch diverse, teils widersprüchliche Ankündigungen zwischen Spring 5.0.9 und Spring 6.1.0 hat sich große Unsicherheit zur Zukunft des RestTemplates verbreitet. Das RestTemplate ist jedoch weder deprecated noch im maintenance mode. Anwendungen, die momentan das RestTemplate verwenden, müssen nicht so schnell wie möglich auf einen der neuen Clients migrieren, um auch zukünftig in Spring-Projekten nutzbar zu sein. Können sie aber, unter Berücksichtigung einiger Punkte, die in Akt 3 erwähnt werden.

TAGS