Posted by mkarg
on July 24, 2011 at 10:55 AM PDT
It's been a few months already that the expert group of JSR 339 started discussion about the details of JAX-RS 2.0. The target defined by spec lead Oracle are clear: Java EE 7 shall have a RESTful API that augments current JAX-RS 1.1 API by (among others) a Client API, HATEOAS support and asynchronous invocations. So what's the current status?
JAX-RS 2.0: A first interim report
It's been a few months already that the expert group of JSR 339 started discussion about the details of JAX-RS 2.0. The target defined by spec lead Oracle are clear: Java EE 7 shall have a RESTful API that augments current JAX-RS 1.1 API by (among others) a Client API, HATEOAS support and asynchronous invocations. So what's the status with state?
As three corner stones of the RESTful team at Sun, Marc Hadley, Paul Sandoz and Roberto Chinnici, left the team quite at the time of JAX-RS 2.0 project planning (Marc left before, Paul abd Roberto soon after) Oracle needed some time to find adequate replacements. So the first thing that happened in the project was the installation of new project leads, Santiago Pericas-Geertsen and Marek Potociar. It took quite several weeks then until Oracle came up with a first discussion topic for the expers: The Client API.
There are several RESTful clients out there already, for example there is one bundled with Jersey. The problem is that those do not fulfil a particular normative API, so the applications using them are necessarily bound to one particular JAX-RS implementation. For in-house projects this might be fine; for ISVs it is not, as it breaks the WORA principle. So, the idea to have all stakeholders (speak: vendors and key users) gathered around a single desk is brilliant to define an API that satisfies all of them, but obviously is a job not to be done whilst lunch break. It took more weeks to get many of those into the team, particularly those thad had some trouble with Sun / Oracle in the past. But in the end it is good to see that besides Oracles, RedHat and others meanwhile Apache is back on board - if not officially, but at least physically.
The Client API was discussed very intensively and from a lot of different angles. There had been several proposals how such an API should look like, what it shall work like, and so on. The discussion is not yet at its end. In fact, it is still going and and it is good that it is going on: As long as all vendors keep talking to each other, chances are good that in the end users can expect to get something really useful and portable. I don't want to get into much details as long as talks are running, but what people can expect is that the API will be rather fluent, allows the implementing engine to work as efficient (say: fast) as possible (e. g. by reusing many parts in the calling chain that possibly are rather expensive to recreate each time), and will allow to enable features in a portable way (like local caching, if provided by the particular engine). Also, support for asynchronous execution and non-blocking calls are under discussion (and I expect both to be definitively in the final API in a portable way), which allows to implement much more effective client applications compared to the current, proprietary clients. Looking back at the features we discussed so far, and at the code one had to write in the past, the client API will become something to really look forward at.
An essential, but often missing, part of REST is HATEOAS (or: support for hypermedia). The discussions about that just have started, but are on a good way. Oracle came up with the interesting view that there are different types of links: Those that change application state, and those that "just" describe structure. Both have to be supported in the best possible way, but as both depend on totally different circumstances, that way has to be different. Structural link are simply static: An order references contained items by some kind of embedded URL of header. This reference is to be expressed as an URL in the representative state and the technology to provide that is under current discussion. State changes are more complex. They follow business rules and the representative links to not link to other business objects but are actions to imply changes to the model's state (like adding more items). These imply more complex API needed, so the discussion about that just started and will go on a while. For both type of links there is not yet any decision made, but it is clear that both should be representable both, as embedded URLs or as Link headers. While the first is typical in XML entities, the latter is useful for any kind of entitiy, including binaries like images.
I will try to update this thread when the expert group comes up with notable news. Meanwhile, I'd be glad if you'd post your comments on the current situation. Is that going in the direction you need? Is there anything you want to tell the experts?
An overview of all my publications can be found on my web site Head Crashing Informatics ( http://www.headcrashing.eu ).