The New Standard for RESTful Web Services
JAXenter speaks to Markus Karg, on the current status of JAX-RS 2.0.
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
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
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
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
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
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
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!