RESTful Web-Services mit JAX-RS

Transkript

1 JUG Stuttgart RESTful Web-Services mit JAX-RS 30. Oktober 2014 Alter Scheuer, Stuttgart-Degerloch Markus KARG (Expert Group JSR 339, 370 / JAX-RS 2.0, 2.1)

2

3 Agenda Was ist nur so toll an diesem REST? JAX-RS Schon wieder eine neue API! Echtes REST mit JAX-RS Die Zukunft von JAX-RS, EJB & Co. Java EE 8 Big Picture

4 Was ist nur so toll an diesem REST? Copyright Markus Karg, Pforzheim

5 Was ist ein Web-Service? Maschine Irgend ein Programm HTTP GET, PUT, POST, DELETE z. B. XML JSON WebServer WWW Mensch Browser HTTP GET, POST z. B. HTML PDF WebServer

6 Vorteile Alles kann mit allem reden, ohne die Anwendungen nennenswert zu ändern. Global und seit Jahrzehnten etablierte Standards (vgl. idocs, CORBA, Treiber) [URL, HTTP, MIME, UTF-8, XML/JSON] Lose Kopplung (nur miteinander reden, nicht miteinander verheiraten) Bestehende Infrastruktur unterstützt uns optimal (Firewalls, Caching, Security) Lingua Franca für M2M

7 Ketzerische Thesen Mehr Clients Mehr Server: Nicht-linear skalierbar O(n 2 )! Non-RESTful Web-Services bilden einen unnötigen Layer oberhalb HTTP...sind oftmals proprietär und erfinden für alles das Rad neu...sind sehr komplex ( CISC-Style ) und oftmals schwer zu verstehen...sind wenig objekt-orientiert, meist RPC oder CRUD...sind meist schwierig zu analysieren, wenn sie klemmen...und bergen viele weitere kleine und große Probleme!...wieso also nicht reines HTTP?

8 Ketzerische Antithesen Das WWW ist Prototyp der idealen Software-Architektur! Nicht Menschen surfen im WWW sondern Maschinen Nicht HTML wird geliefert sondern XML oder JSON Nicht Buttons bieten Aktionen an, sondern Link-Header Internet WWW der Dinge

9 REST Representational State Transfer [Fielding, 2000] Resource = Ampelanlage an einer Kreuzung Representational State = Ein XML- oder JSON-Dokument mit der Information, welche Ampel gerade welche Farbe zeigt Die Zusendung des Dokuments an die Steuerung schaltet die Farben der einzelnen Ampeln aus der Ferne. REST ist ein Paradigma, keine Technologie. Adressierbare Ressourcen {+ verhandelbares Datenformat} + Verben + Zustandslosigkeit + HATEOAS Speziell im Web: URL {+ MIME} + HTTP + Matrix-Params + Link-Header HATEOAS Hypermedia As The Engine Of State: Status des Maschine-Maschine-Dialogs steckt in der Nachricht selbst, nicht im Client und auch nicht im Server. (

10 REST ist toll! Unbegrenzte Skalierbarkeit Jeder Server bringt zusätzliche Leistung Mehr Clients pro Server da kein Status auf dem Server Kein SPOF; Reboot und Neuinitialisierung eines beliebigen Servers Wir müssen nichts neues lernen, wir machen einfach das WWW nach! Firewalls, Caches, Sicherheit... geschenkt! Mitlesen der Kommunikation im Klartext wenn's klemmt 1:1-Zuordnung von HTTP-Aufrufen zu Aktionen Keine spezielle Software-Unterstützung nötig......und wozu braucht man dann dieses JAX-RS?!

11 Schon wieder eine neue Java-API...! :-(

12 JAX-RS vs JAX-WS/RPC JAX-WS, JAX-RPC SOAP, meist Remote Procedure Call, meist stateful, WS-Darkstar, schwergewichtig und komplex JAX-RS REST/HTTP, stateless, leichtgewichtig und simpel

13 JAX-RS vs Servlet API Servlet-API Ersatz für CGI und ISAPI/NSAPI, entbindet Java-implementierte Server-Extensions von der Kenntnis der zugrundeliegenden, nativen Server-API (Bottom-Up, Technologie- Wrapper). Vereinheitlicht Web-Server-Produkte (z. B. Apache, IIS). JAX-RS Erleichtert das Schreiben von RESTful Web Services in Java (Top-Down, Anwendungs- Framework) durch Abstraktion des Domänenmodells von der Technik. Vereinheitlicht Java-REST-Frameworks (z. B. Jersey, Apache CXF).

14 JAX-RS vs JSF Java Server Faces Zum Schreiben von Anwendungen mit Web-Oberfläche (für Menschen). GUI-zentrisch. JAX-RS Zum Schreiben von Web Services (für Maschinen). Domänenmodell im Zentrum.

15 REST Maturity Model 0 SOAP oder RPC/XML Einzelne URI für gesamten Service Einzelnes HTTP-Verb für alle Aktionen 1 + Natives HTTP + Verschiedene URIs für getrennte Ressourcen 2 + Verschiedene HTTP-Verben (DELETE, OPTIONS, HEAD...) 3 + HATEOAS (Hypermedia-Navigation)... Basics seit JAX-RS Copyright Markus Karg, Pforzheim

16 JAX-RS-Universum JAX-RS Container hostet eine JAX-RS-Anwendung (= Web Application) Web Application besteht aus Web Resources und Extensions (Filter, Provider, etc.) Automatisches Finden und Montieren der Anwendung, lose Bindung Starke Erweiterbarkeit durch klar definierte Schnittstellen innerhalb des Containers IoC, POJOs, deklarative Programmierung mittels Annotations Context and Dependency Injection Domänen-orientiert, automatische Codierung/Dekodierung Unabhängig von Servlets / JSF

17 Echtes REST mit JAX-RS

18 Adressierbarkeit curl public class Konto { private IBAN iban; Konto und IBAN sind Objekte, keine Strings! Wir kümmern uns nicht um deren Erzeugung!

19 Verhandelbares Datenformat curl -H "Accept: application/xml;application/json" --data "Markus Karg" public Eroeffnungsbestaetigung kontoeroeffnen(eroeffnungsantrag antrag) { String neuekontonummer = " "; String kontoinhaber = antrag.getantragsteller(); return new Eroeffnungsbestaetigung(neueKontonummer, kontoinhaber); public class JaxbWriter implements MessageBodyWriter<Object> { } XML wird über JAXB (noch) automatisch unterstützt JSON wird in den meisten Produkten automatisch unterstützt

20 Zustandslosigkeit curl public class Konto private String iban; public Kontoauszug Monat int int bis) { return new Kontoauszug(iban, monat, von, bis); } Zustand wird automatisch aus dem Request hergestellt Zustand (Monat) ist ein Objekt, kein String!

21 Verben curl -X DELETE public class Konto private IBAN iban; public Kuendigungsbestaetigung kuendigen() { return new Kuendigungsbestaetigung(iban); } Verben sind Annotations HTTP (nahezu) vollständig enthalten Beliebige eigene Verben möglich (z. B. MOVE)

22 public Response UriInfo uri) { Link.Builder b = Link.fromUri(uri.getPath()); Link self = b.rel("self").build(); Link kontoauszugabrufen = b.rel("kontoauszug").build(); Link kuendigen = b.rel("kuendigen").build(); Link betragabheben = b.rel("abheben").build(); ResponseBuilder r = Response.ok().links(self, kontoauszugabrufen, kuendigen); if (saldo.compareto(zero) > 0) r.links(betragabheben); return r.build(); } < HTTP/ OK < Server: Apache-Coyote/1.1 < Link: <konten/de1234>; rel="self" < Link: <konten/de1234>; rel="self kontoauszug" < Link: <konten/de1234>; rel="self kontoauszug kuendigen" < Link: <konten/de1234>; rel="self kontoauszug kuendigen abheben" < Content-Length: 0 < Date: Wed, 16 Jul :42:22 GMT verbesserungswürdig

23 JAX-RS Features Vollständig typisiert, Anwendung ist von Technik isoliert Kein Hantieren mit Strings, Streams oder HTTP HTTP/1.1 incl. ETags und Conditional Requests zur Leistungserhöhung Separation of Concerns (Anwendungsdomänen-POJOs Datenstrom-Ebene) Auto Discovery, Konfigurations-API (Properties injizieren und ändern), CDI Dynamic Sub-Resources Mapping (z. B. Wenn dann Pfad auf Resource A mappen, sonst auf Resource B ) HTTP-Headers POJOs Providers Entity Providers (MBR, MBW), viele Standard-Provider u. a. JAXB, JSON Content Negotiation Context Resolvers (z. B. JAXBContext) Exception Mapping Providers (Exception HTTP-Status-Code) WebApplicationException Security Bean Validation API Asychronous Programming (Multi-Fiber-Support verbesserte Skalierung) Client API (Wiederverwendbare Session und vorbereitete Aufruf-Templates) Static & Dynamic Filters (Datenstrom-Ebene) und Interceptoren (Java-Objekte) für Caching, Compression, etc. HTTP-basierte Anwendungs- Infrastruktur

24 Resources JAX-RS 2.0 Specification PDF and JavaDocs JAX-RS 2.0 JavaDocs Online JAX-RS 2.0 Reference Implementation (Jersey) Maven GAV Coordinates: <groupid>javax.ws.rs</groupid> <artifactid>javax.ws.rs-api</artifactid> <version>2.0</version> Adopt JAX-RS!

25 Die Zukunft von Java EE We plan to enhance the managed bean model to make ease of use features that are currently available only to selected components available to all managed beans via the mechanisms provided by CDI. (JSR 366 / Bill Shannon et al.)

26 Die Zukunft von Java EE Auf lange Sicht nur noch ein Container und ein Bean-Typ (i. S. Cloud-POJO ) EJB i. S. JAX-WS, Stateful Beans, JRMI und IIOP stirbt aus (IIOP, EJB 2 optional in EE 8) Aus EJB-Typen (TX, Timers, MDB, Resource-Access) werden hinzufügbare Fähigkeiten Aufsplittung in reines REST und MVC API Gemeinsame Infrastruktur in Diskussion Zielarchitektur: Lightweight Cloud : JAX-RS + CDI-annotierte Fähigkeiten

27 Die Zukunft von Java EE Java EE = JAX-RS + CDI + Injectable Features MVC = JAX-RS 2.0 Non-REST + JSF 2.2 Facelets & Flows JAX-RS 2.1 = JAX-RS MVC JSF 2.3 = JSF MVC MVC API's JAX-RS-Basis ist noch spekulativ!

28 Die Zukunft von JAX-RS Server-Sent Events: Der Todesstoß für JMS und AMQP? Weniger JAX-RS-Annotations, mehr CDI! Deklarative Sicherheit (Java EE) Nicht-blockierende Filter, reactive Client API JAXB wird optional JSONB API vermutlich zwingend Verbessertes HATEOAS (mehr REST) JAX-Resources = MVC-Controller

29 Die Zukunft von EJB Das EJB-Team bei Oracle existiert allem Anschein nach nicht mehr. Führende Mitarbeiter des EJB-Teams wurden anderen Teams zugeordnet. Oracle wird ein Team formieren, sollte es eine Notwendigkeit für eine neue EJB-Version geben. (Reza Rahman, Oracle) Es gibt bis heute keinen JSR für eine neue EJB-Version.

30 Die Zukunft von JSF...the scope of new features is intentionally limited......the set of issues addressed is very much up to what the expert group is willing to contribute... (JSR 372, Edward Burns et al.) Interpretation: Oracle hat nicht vor, neue Features in nennenswertem Umfang beizusteuern. Wenn die Community ein Feature vorschlägt, soll sie es auch gleich programmieren!

31 Q & A