Ein erster Blick auf die wichtigsten Neuerungen in JAX-RS 2.0

Rund gemacht

Thilo Frotscher


Die Arbeiten an JAX-RS 2.0 sind bereits seit 2011 im Gange. Kurz vor Jahresende 2012 liegt die Spezifikation nun als Public Review vor. Die Referenzimplementierung, die wie gehabt im Rahmen des Jersey-Projekts [1] erstellt wird, hat den Meilenstein 9 erreicht. Somit sind die Arbeiten zwar noch nicht vollständig abgeschlossen, und es kann nicht ausgeschlossen werden, dass sich das Eine oder Andere kurzfristig noch ändert. Das wesentliche Erscheinungsbild von JAX-RS 2.0 dürfte aber inzwischen feststehen. Grund genug also, sich genauer anzusehen, was Entwickler von dem neuen API erwarten dürfen. Im Folgenden werden die wichtigsten Neuigkeiten vorgestellt.

Client-API

Die sicherlich wichtigste Neuerung in JAX-RS 2.0 besteht in der Standardisierung des Client-API. Zwar konnten auch bislang schon Clients für REST-Anwendungen mit den diversen Frameworks implementiert werden, nur verwendeten diese eben alle proprietäre Client-APIs. Bei der Entwicklung des Standard-API für die Clientseite wurden nun Ideen und bewährte Konzepte sowohl aus diversen proprietären Lösungen, als auch von dem bereits standardisierten serverseitigen API zusammengeführt.

Als Einstiegspunkt in das neue Client-API dient die Klasse ClientFactory. Wie der Name vermuten lässt, dient sie als Fabrik für Objekte, die das Interface Client implementieren, und bietet hierfür entsprechende Methoden. Die Implementierungsklasse des zurückgelieferten Client ist spezifisch für das eingesetzte Framework. Im Falle von Jersey handelt es sich beispielsweise um die Klasse JerseyClient.

Hat man einen Client erhalten, können dort optional Provider oder Features registriert werden. Provider dienen dazu, Erweiterungen und Anpassungen für das Framework zu realisieren. Die bereits von dem serverseitigen API bekannten MessageBodyReader und MessageBodyWriter sind Beispiele für solche Provider. In ihrem Fall besteht die Erweiterung daraus, spezifische Umwandlungen zwischen Ressourcen und bestimmten Repräsentationen zu implementieren, die das Framework von Haus aus nicht unterstützt.

Während Provider bereits aus JAX-RS 1.1 bekannt waren, sind Features ein neues Konzept in JAX-RS 2.0. Sie sind letztlich nichts anderes als ein spezieller Typ von Provider, sie sollen also ebenfalls der Erweiterung des Frameworks dienen. Der Unterschied zwischen beiden liegt darin, dass Features eine umfangreichere Erweiterung kapseln sollen, die beispielsweise aus mehreren Providern und gegebenenfalls zusätzlichen Laufzeitkonfigurationen bes...

Ein erster Blick auf die wichtigsten Neuerungen in JAX-RS 2.0

Rund gemacht

Thilo Frotscher


Die Arbeiten an JAX-RS 2.0 sind bereits seit 2011 im Gange. Kurz vor Jahresende 2012 liegt die Spezifikation nun als Public Review vor. Die Referenzimplementierung, die wie gehabt im Rahmen des Jersey-Projekts [1] erstellt wird, hat den Meilenstein 9 erreicht. Somit sind die Arbeiten zwar noch nicht vollständig abgeschlossen, und es kann nicht ausgeschlossen werden, dass sich das Eine oder Andere kurzfristig noch ändert. Das wesentliche Erscheinungsbild von JAX-RS 2.0 dürfte aber inzwischen feststehen. Grund genug also, sich genauer anzusehen, was Entwickler von dem neuen API erwarten dürfen. Im Folgenden werden die wichtigsten Neuigkeiten vorgestellt.

Client-API

Die sicherlich wichtigste Neuerung in JAX-RS 2.0 besteht in der Standardisierung des Client-API. Zwar konnten auch bislang schon Clients für REST-Anwendungen mit den diversen Frameworks implementiert werden, nur verwendeten diese eben alle proprietäre Client-APIs. Bei der Entwicklung des Standard-API für die Clientseite wurden nun Ideen und bewährte Konzepte sowohl aus diversen proprietären Lösungen, als auch von dem bereits standardisierten serverseitigen API zusammengeführt.

Als Einstiegspunkt in das neue Client-API dient die Klasse ClientFactory. Wie der Name vermuten lässt, dient sie als Fabrik für Objekte, die das Interface Client implementieren, und bietet hierfür entsprechende Methoden. Die Implementierungsklasse des zurückgelieferten Client ist spezifisch für das eingesetzte Framework. Im Falle von Jersey handelt es sich beispielsweise um die Klasse JerseyClient.

Hat man einen Client erhalten, können dort optional Provider oder Features registriert werden. Provider dienen dazu, Erweiterungen und Anpassungen für das Framework zu realisieren. Die bereits von dem serverseitigen API bekannten MessageBodyReader und MessageBodyWriter sind Beispiele für solche Provider. In ihrem Fall besteht die Erweiterung daraus, spezifische Umwandlungen zwischen Ressourcen und bestimmten Repräsentationen zu implementieren, die das Framework von Haus aus nicht unterstützt.

Während Provider bereits aus JAX-RS 1.1 bekannt waren, sind Features ein neues Konzept in JAX-RS 2.0. Sie sind letztlich nichts anderes als ein spezieller Typ von Provider, sie sollen also ebenfalls der Erweiterung des Frameworks dienen. Der Unterschied zwischen beiden liegt darin, dass Features eine umfangreichere Erweiterung kapseln sollen, die beispielsweise aus mehreren Providern und gegebenenfalls zusätzlichen Laufzeitkonfigurationen bes...

Neugierig geworden?


    
Loading...

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