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 contains some documents corresponding to the JSR process - drafts, meeting minutes, mailing lists, etc.
The Jersey project at java.net is the home for 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 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"?
2 comments:
Hi Patrick,
Regarding the Restlet project, I'd like to make a few remarks:
1) Trademark
"Restlet" is a trademark for defensive reasons mainly. No need to add a 'TM' when you mention it in your blog posts. Actually, you should append a ® as it is a registered trademark ;-)
It is not different from the fact that Java, JBoss, Hibernate, IBM are also trademarks. Really nothing new under the sun here.
2) Licensing
You don't seem to like CDDL, but we are now licensed under a triple licensing scheme. You can choose between:
- CDDL 1.0
- LPGL 2.1
- LGPL 3.0 (compatible with Apache license)
See details here.
3) JSR-311
We are also part of the JSR EG and have an implementation of the specification on top of the Restlet API since version 1.1 M3.
Therefore we offer more licensing freedom than Jersey if this is a concern for you.
See details here.
I hope you will give us a second chance!
Best regards,
Jerome Louvel
Jerome, thanks for the comments. Some of the issues had already been raised by other folks - I thought here, but must have been off-line, or some other venue, so I'm happy to see you raise them here. Specially the licensing issue.
I should have also noted that I have certainly seen plenty of positive reviews of the Restlet project; folks should definitely take a look at it.
In the end, I welcome all these projects; the diversity is what ends up allowing us to evolve in a natural way - noting that it's a bit of a shame we didn't see this kind of diversity earlier, when the Servlet work was started and became the defacto Java-server interface.
Post a Comment