Sun has submitted JSR-311, Java API for RESTful Web Services, to the Java Community Process. No useful information is provided in the specification as to what they're actually proposing. However I can't help but think that this is a horrible idea.
A major selling point of REST is that it's simple. It doesn't require big, complicated frameworks with seven levels of indirection to solve simple problems. However there are some companies (Sun being one of them) that can't imagine regular, ordinary developers building systems without using some ultra-complex framework they've designed. The idea that people might just want to send plain old XML over plain old HTTP is inconceivable to them. There has to be some big framework for serializing objects and abstracting databases and faking method calls and guaranteeing message delivery and a dozen other things people either can already do perfectly well with HTTP and XML or don't actually need to do at all.
What would be helpful would be a serious rethink of Java's HTTP functionality. Client-side, something like Apache HttpClient
that has full and complete support for cookies, authentication, ETags, If-Modified-Since headers, PUT, POST, DELETE, HEAD, GET and so forth would really make it a lot easier to build RESTful systems in Java. Yes, you can sort of make all this stuff work now, if you squint your eyes and look at the problem crosswise; but it's really ugly and hard. Rather than designing the best possible HTTP API, Sun opted for a lowest-common-denominator API for all protocols.
Guess what? Not all protocols are the same. FTP, HTTP, file, and mailto are very different things. Any API that tries to cover all these is guaranteed to fail at least three and probably all of them.
URLConnection class suffers from genericity disease.
However, although the proposal is very vague, I don't think that's what we're going to get. Rather than an API that exposes HTTP to programmers in a straightforward way, this group is likely to try to hide HTTP from programmers. Consider this statement:
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.
Actually no. It's a lot easier to build systems on top of plain old XML and HTTP than by trying to work with confusing messes like JAX-WS, SOAP, and object serialization. They are right about the servlet API, but that's because the servlet API was designed without considering REST (or without considering user interface principles in general). The problem is not HTTP or requiring developers to understand it. The problem is that Sun's server-side HTTP API blows chunks. Like the client side API, it suffers an overly generic focus (not just HTTP but potentially all server-side protocols) and an unfamiliarity with the actual HTTP spec they were trying to model. No wonder RESTful development with servlets is hard. We need to replace the servlet API with something more RESTful and usable, not hide HTTP completely. RESTlet might be a good start.
Finally, like all too many JCP specs, this group proposes to develop, experiment, and standardize at the same time. There is little prior art in this space, and what there is, is likely to be unknown to or ignored by the working group. Instead they are going to try to lock out competing alternatives by pronouncing their creation to be the standard and bundling it with the Java standard edition. This won't work. When a standard sucks, it will be replaced by better third party alternatives. Just consider Hibernate and Spring vs. J2EE or RELAX NG vs. W3C XML Schema. However, preempting other efforts can delay the adoption of better technologies by years and cause much pain along the way.
Comments are due by February 26. Please ask Sun to reconsider this proposal.