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:
The jsr311 project at java.net containssome documents corresponding to the JSR process - drafts, meeting minutes, mailinglists, etc.
TheJersey project at java.net is the homefor the open source reference implementation (RI) of JSR 311.
Some of the positive aspects of the ongoing effort:
It's good to be thinking about some facility to help peoplewith RESTful services, in Java.
This JSR seems to be much, much more transparent than mostJSRs; 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! Themost recent one is the"Editors draft - July 3rd, 2007 (PDF)".
The general approach as currently implemented / described byJersey feels more or less right. Of course, I say that because I'vebeen recently looking at doing something similar, without havingseen 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 annotationsto augment methods and classes which describe the services, specifically.Some of the annotations I had come up with were in fact the exact samenames that Jersey uses!
OK, now for the bad news.
The licensing for the open source side only accommodates theGPL half of the universe. Leaving folks wanting something more likea BSD style license, to fend for themselves. Of course, that's notnecessarily bad, it's always useful to have some competition. But it'salso nice to have a single common implementation that everyone canuse. There aremany licensesthat 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 willrequire 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 changeanything 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 providesuch functionality.
Read: We'll figure this out later; hopefully we won't have to change anythingin 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 alternateimplementation to be developed. This might be something thatApache would typically do, but given theApache / Sun disagreement on JCP issues,it's not really clear to me that Apache will ever be interested in working onJSR implementations again.
Another interesting wrench to throw into the gears is Eclipse. As of Eclipse 3.3,the Equinox projecthas been shipping Jetty,along with some goop to allow you to use OSGi within servlets, orstart an HTTP server as an OSGi service.Adding RESTful service support to this story seems like a logicalnext step to me. Note that the existing JSR 311 non-goal ofsupport for <= Java 5 support violates an OSGi constraint ofrunning in their smaller (1.4.x-ish) environments.
Seems to me, if we're going to have to work on an alternate implementationanyway (to solve the licensing issues), we might as well solve some ofthe technical problems as well (J2ME / Java 1.4 support, service descriptions,client apis, etc).
Anyone up for a "Battle of the RESTful frameworks"?