Sun has submitted JSR 311, Java API for RESTful Web Services, to the JCP. According to the introduction:
This API will enable developers to rapidly build Web applications in Java that are characteristic of the best designed parts of the Web. This JSR will develop an API for providing REST(Representational State Transfer - See reference to Roy Fielding’s dissertation in section 3.1) support in the Java Platform. Lightweight, RESTful approaches are emerging as a popular alternative to SOAP-based technologies for deployment of services on the internet. Currently, building RESTful Web services using the Java Platform is significantly more complex than building SOAP-based services and requires using low-level APIs like Servlets or the dynamic JAX-WS APIs. Correct implementation requires a high level of HTTP knowledge on the developer’s part.
Supporting the JSR in addition to Sun are Apache, BEA, Doug Lea, Google, JBoss, TmaxSoft, and Jérôme Louvel, who is the creator of the RESTlet Java framework.
One of the spec leads is Sun’s Marc Hadley, who answered some questions for InfoQ.
First, we asked why he feels a REST-specific JSR is needed, i.e. why Servlets and JSPs are not enough. We also questioned the spec’s wording about low-level APIs, and how one would go about developing RESTful web apps without a deep understanding of HTTP issues and design patterns. Marc replied that while the current APIs provide broad support for HTTP, they leave a lot of work to the developer that could be automated in a higher level API:
Developers currently have to manually implement support for things like content negotiation and preconditions. A higher level API could offer default support for these and simplify the job of building a well-behaved application. In addition, current APIs don’t really highlight important things that a developer should focus on like support for the ETag and Last-Modified headers that are the basis for caching. A high level API that embodies HTTP patterns will help to lead developers down a good design path.
Concerning support for WADL, a supposedly Web-friendly description language designed by Marc, he explained that WADL is still somewhat experimental:
I think it would be premature to require support for it in the JSR. That said, I think a declarative annotation-driven approach will lend itself well to translation to and from WADL and I’d like to experiment with that outside of the JSR.
Marc confirmed that this does not mean Sun is aiming to shifts its focus from Web services (WS-*) to the Web:
Its not a question of either-or, we’ll continue to invest in both. With this JSR, we want to provide the same ease of development for RESTful services that JAX-WS and WSIT now provide for WS-* based services.
Reactions in the REST community have been mixed. In the Yahoo! REST discussion group, Elliotte Rusty Harold started a thread that echoed some harsh comments from his own blog entry:
Remember, these are the same jokers who gave us servlets and the URLConnection class as well as gems like JAX-RPC and JAX-WS. They still seem to believe that these are actually good specs, and they are proposing to tunnel REST services through JAX-WS (Java API for XML Web Services) endpoints.
They also seem to believe that “building RESTful Web services using the Java Platform is significantly more complex than building SOAP-based services”. I don’t know that this is false, but if it’s true it’s only because Sun’s HTTP API were designed by architecture astronauts who didn’t actually understand HTTP. This proposal does not seem to be addressing the need for a decent HTTP API on either the client or server side that actually follows RESTful principles instead of fighting against them.
In the same thread, Mark Baker has some criticism of his own, but concludes:
Anyhow, rather than be critical of this effort, I’ve decided to submit my application to join the EG. Java definitely needs better APIs for the Web.
XFire developer Dan Diephouse writes:
This is excellent news - I’m glad to see people are thinking more seriously about RESTful services on Java.
With the number of companies already supporting this JSR, there seems to be little doubt that it’s going to go forward through the JCP process. The current timeline expects a first draft in June 2007, and a final release in March 2008.
Pete Lacey’s reaction is probably shared by many:
Update: Marc Hadley provides some additional background in a blog entry.
- Cool!
- The servlet API is not ideal, this is needed.
- I hope they don’t screw it up (see JAX-WS).