The New Standard for RESTful Web Services
JAXenter speaks to Markus Karg, on the current status of JAX-RS 2.0.
Markus Karg graduated in Staatlich geprüfter Informatiker and has been working with distributed systems since 1997. He has influenced the JAX-RS specification since its early days. In 2008, he started a Jersey sister project for supporting the WebDAV protocol family. He is responsible for implementation and design at QUALITY QUALITY GmbH & Co KG, as his main employment.
In January, JSR 339 passed the JSR review ballot with eleven yes votes, and work is currently underway for developing the next version of the JAX-RS API for RESTful Web Services. In this interview, we speak to Markus Karg on the current status of JAX-RS 2.0, what the expert group have planned for the API, and whether we can expect JAX-RS 2.0 to arrive on schedule.
JAXenter: The Expert Group has started work on JAX-RS 2.0. One of the main new features will be a unified Client API. What exactly do you have planned here?
Markus Karg: The JAX-RS 1.1 specification developed under JSR 311 concentrated solely on the server area. So far, there has been no standardised support for writing clients in Java that access RESTful Web Services. Users have been coerced into making detours, for instance, by using the JRE class HttpURLConnection, which results in relatively complex code, or using proprietary products like the Apache Wink client or the Jersey client, which leads to non-portable applications.
So, to simplify writing clients on the one hand, and to allow the easy migration from Wink to Jersey (or vice versa) on the other hand, it is necessary to standardise the client side, too. In principle, there are several possible ways to do this: we could agree on the API of an established product, but that is only advantageous for that particular clientèle. We could also agree on a completely new API, but that requires more effort, for what might be little additional benefit.
Oracle has proposed two APIs in parallel, one on a very high level of bstraction for the “normal user,” and a more complex one for special use cases. Here, in principle, all options are still open. But, we are only at the beginning of this discussion. We will examine the existing APIs in detail and decide which route offers the most benefits to the user.
Since Apache has left the Java Community Process there are certain tendencies towards Oracle, and Oracle supplies the Jersey reference implementation. This is not a pro-Jersey argument, because Red Hat (JBoss) and others still have seats in the expert group.
JAXenter: What about the support for asynchron processes? It was debated whether WebSocket-Support should be a part of JAX-RS 2.0…..
Markus: COMET and WebSockets support the paradigm of asynchronous messaging. COMET is an approach formulated in HTTP, and WebSockets acts as counterpart at the HTML level. They permit “pushing” of information to the client, i.e the server is sending a message to the client which, at that moment, occurs regardless of when the client requested such a notification. This saves the overall client-transport-server-system from a gazillion of more or less useless squandered request-response roundtrips, which are necessary in the “polling” principle, and increases the message’s actuality.
Known is “pushing” mostly from the area of message oriented middleware, like JMS or AMQP. But those are often backed by proprietary protocols or at least protocols that do not belong to the web layer, hence they are relatively complex to handle, e. g. at firewall setup and so on.
It makes sense to use asynchronous messaging on RESTful applications, too: for instance, on a trading platform a server could distribute price changes asynchronously among the clients, without each client being required to constantly request a complete price list – which may not have even changed! Unfortunately, Oracle couldn’t bring itself to address this topic in JAX-RS 2.0 and has deferred COMET and WebSockets to a later specification.
Whether this means COMET and Websockets are postponed indefinitely, only time will tell. What is clear, is that Oracle provides the reference implementation, and the decision-making process reflects this. I can only speculate about the reasons for this exclusion, but it is worth bearing in mind that even Oracle does not have infinite resources at their disposal.
JAXenter: What other new features are in the pipeline for JAX-RX 2.0?
Markus: Many applications taking credit for supporting the Rest paradigm are, strictly speaking, not RESTful at all (there has even been attempts to define a label for such applications) because they do not fulfil one fundamental aspect: HATEOAS (Hypermedia As The Engine Of Application State). JAX-RS 2.0 will add support for Hypermedia and will allow applications to, for example, inject relations (URIs) into entities, or send them to the client as Link headers. This way, the client learns from the received responses what a relation means, and can use this knowledge to initiate a particular process. Just like a browser can tell the user: “click on this link to place the order,” a RESTful client can obtain the same information – just in machine readable form. This enables complex processes to be built up, without programming them statically in the client.
With HATEOAS, control over which step should be implemented next, respective of which state a process is currently in, moves from the involved clients and servers, into the transported medium itself. Client and server are not required to remember anything, and instead learn everything necessary by analysing the medium and manipulating it according to their intentions. I rate this as the most essential new feature, besides the client API.
However, Oracle has added more items to the agenda, including support for MVC, i.e using JAX-RS resources as controllers, parameter validation, replacing their own annotations with CDI (hence a more tighter integration into Java EE) and more. The complete list of items suggested by Oracle can be viewed at JCP.org, since this project implements a transparent information policy.
Last but not least, there are all the small discussion points added to the tracker by the users, and these must certainly get reviewed by the expert group, too. Resolving these issues represent a higher value than large innovations such as HATEOAS and COMET, for many users. Aware of this, Oracle has promised to fix all of such issues, which are deemed as failures of the JAX-RS 1.1 specification.
JAXenter: The reference implementation for JAX-RS is the Jersey project. What is the relationship between the expert group and the Jersey developers?
Markus: Generally, the JCP presents itself as being democratic, and the expert group as independent of the Jersey developers. Officially, the expert group defines the specification and the Jersey developers implement it in Java Code. But, in reality the Jersey developers are Oracle employees, Oracle is leading the work group, defining the agenda, and providing solutions for most items, since Jersey is already able to fulfil most of the problems that arise.
In the past, the Jersey developers have participated in an open and constructive dialogue with users and competitors. Ideas and code from other projects have been merged into Jersey, sometimes directly from the experts. I am curious whether this holds true after the departure of the previous spec leads Marc Hadley and Paul Sandoz from Oracle (both former Sun employees.) I hope this dialogue is maintained, for the sake of achieving the best possible, and most widely adopted standard, and since unilaterally pushing through their own product will help nobody, not even Oracle, since competitive implementations like RestEasy and Wink are rather popular.
Unfortunately, some former experts are absent from this JSR, partially due to political reasons, which does nothing to improve the situation for the remaining participants. I’m curious myself as to what will happen over the next few months.
JAXenter: What are the next steps?
Markus: The present Co Spec Lead Paul Sandoz will leave Oracle in February. Following the JCP bylaws, Oracle will appoint a successor and, since Sandoz is currently the central figure of Jersey, establish a new developer for this project. Obviously, this will not happen over night.
As soon as this happens, Oracle will coordinate the next stages for the expert group: i.e provide an agenda, decide which topics are to be discussed, when and in what form. Until then, the expert group members are free to discuss among themselves, but cannot make any real decisions. So, in short, we are currently waiting on Oracle.
JAXenter: And when can we expect the final version of JAX-RS 2.0 and the reference implementation?
Markus: If there is one constant in the software universe, it’s that no release date has ever been met. Oracle provided a tight schedule for JSR 339 and a lot of discussion topics. As we do not intend to just rubber-stamp the existing Jersey code – and I don’t believe, Oracle expects us to do so – I would refer to the proposed release date of Q2/2012 as very ambitious.
Smaller projects have failed to meet more generous deadlines. I would be happy if we manage to meet the release date, but since several projects have to be coordinated and the expert group members have to work on other projects too, it’s unlikely all deadlines and topics will be fulfilled.
The absolute deadline is the release date of Java EE 7, since the platform will contain JAX-RS 2.0. And, currently, there is not even a JSR for that.
JAXenter: Thank you very much!