Some thoughts on
JSR 311 - JAX-RS: The Java™ API for RESTful Web Services.
The description of the JSR, from the web page is:
"This JSR will develop an API for providing support for RESTful (Representational State Transfer) Web Services in the Java Platform."
Here are a few related links:
Some of the positive aspects of the ongoing effort:
It's good to be thinking about some facility to help people
with RESTful services, in Java.
This JSR seems to be much, much more transparent than most
JSRs; published meeting minutes (though a bit skimpy), mailing lists,
reference implementation work being done in the open, etc. Wonderful.
Wonderful!
Even the current drafts of the spec are available, on-line,
without a soul-sucking click-through license agreement! The
most recent one is the
"Editors draft - July 3rd, 2007 (PDF)".
The general approach as currently implemented / described by
Jersey feels more or less right. Of course, I say that because I've
been recently looking at doing something similar, without having
seen JSR 311, and there's a lot of commonality between the road I
was heading down, and the one JSR 311 is going down. Use of annotations
to augment methods and classes which describe the services, specifically.
Some of the annotations I had come up with were in fact the exact same
names that Jersey uses!
OK, now for the bad news.
The licensing for the open source side only accommodates the
GPL half of the universe. Leaving folks wanting something more like
a BSD style license, to fend for themselves. Of course, that's not
necessarily bad, it's always useful to have some competition. But it's
also nice to have a single common implementation that everyone can
use. There are
many licenses
that would be compatible with the GPL and acceptable to a wider audience.
Specific issues from the 2007/07/03 spec draft: Section 1.2 Non-Goals:
Support for Java versions prior to J2SE 5.0:
The API will make extensive use of annotations and will
require J2SE 5.0 or later.
Read: Sorry, J2ME. Sorry, folks stuck on Java 1.4.
Description, registration and discovery: The specification will neither
define nor require any service description, registration or discovery capability.
Read: We'll figure this out later; hopefully we won't have to change
anything in this spec once we start thinking about this aspect of the problem.
Client APIs: The specification will not define client-side APIs. Other specifications are expected to provide
such functionality.
Read: We'll figure this out later; hopefully we won't have to change anything
in this spec once we start thinking about this aspect of the problem.
The licensing issue is bad enough that it's really going to force an alternate
implementation to be developed. This might be something that
Apache would typically do, but given the
Apache / Sun disagreement on JCP issues,
it's not really clear to me that Apache will ever be interested in working on
JSR implementations again.
Another interesting wrench to throw into the gears is Eclipse. As of Eclipse 3.3,
the
Equinox project
has been
shipping Jetty,
along with some goop to allow you to use OSGi within servlets, or
start an HTTP server as an OSGi service.
Adding RESTful service support to this story seems like a logical
next step to me. Note that the existing JSR 311 non-goal of
support for <= Java 5 support violates an OSGi constraint of
running in their smaller (1.4.x-ish) environments.
Seems to me, if we're going to have to work on an alternate implementation
anyway (to solve the licensing issues), we might as well solve some of
the technical problems as well (J2ME / Java 1.4 support, service descriptions,
client apis, etc).
And yes, I do know of
RESTlet™
but have not looked at it extensively;
the
licensing
and
Joint Copyright Agreement
and
trademark
issues are non-starters for me.
It is also
on a pathway towards becoming a JSR.
Anyone up for a "Battle of the RESTful frameworks"?
