I've been musing on what a REST toolkit/framework would look like for some time. I believe that adoption by the unwashed masses will only happen when a suitable toolkit arrives on their platform of choice. Of course, the very notion of a REST toolkit/framework is a bit specious to the REST zealots, so today I was not surprised to see the newly introduced JSR-311, Java API for RESTful Web Services promptly lambasted by the ever engaging ERH.
One thing I do agree with from the JSR is that the facilities available for easily building RESTful services in Java are too low level. I like Bill de hÓra's ideas in REST wins, noone goes home:
When REST becomes a mainstream/default development approach, as opposed to a fringe/implicit one, a couple of things come to mind on the plus ca change front. First off, I think you’ll see better support for URI design and mapping onto code in server libraries. Also, better access to headers (especially caching and timestamping directives). More awareness and support for the full range of HTTP methods and response codes. Attribute modifers and declarations on methods that have side-effects. Exception designs based around 5xx and 4xx response codes. Media type dispatching. Less emphasis on cookies, more support for digest authentication. More flexbility in LAMP stacks for writing out stuff that isn’t HTML (esp. JSON and Atom serializers). That sort of thing. Overall a gradual lifting on HTTP/REST concepts and idioms into application code.
I'll be keeping a close eye on this JSR to see who gets involved. Hopefully this will not become the white elephant that EJB became.