An open source project called Restlet is creating what is called a Restlet API as an alternative to the Servlet API to adopt REST (Representational State Transfer) with Java. The belief is that the Servlet API does not have a clear separation of concerns between the transport protocol and the application. The Servlet API is an object-oriented view on top of the Http request/response model. On the other hand, the REST perspective has a resource-oriented view. What this means is that domain concepts are resources which can be referenced with a URI and which can be manipulated by components. The representational state of resources, and not resources themselves, is what is exchanged and connectors provide a means for communication of these representations between components. This also alludes to the redundancy in separation of web components as clients and servers. They could simultaneously be both.
1060 NetKernel is another interesting REST and Java project. It is a REST based microkernel and application server.
Looking at these initiatives, the questions then are:
Is the object-oriented view non-optimal for the web?
Does Java need new definitions for REST?
If you are not already familiar with REST, then read Roy Thomas Fielding’s dissertation at http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm
I've tried Restlet. It's probably a pretty good project for reasons that are more sophisticated than I was willing to spend the thought capital on. Why? The servlet api is perfectly capable of creating a rest-like web service. Restlet throws away all of the work, libraries and developer training around servlets and builds the wheel from ground up. Ech. Not suprisingly, it turns out the RESTlet api is quite similar to servlet api.
REST implementations are, by definition, constrained to very few verbs: GET, POST, PUT, DELETE. Quite conveniently, the servlet api already has corresponding methods defined in HttpServlet: doGet(), doPost(), doPut(), doDelete(). Doing REST with java isn't any harder than simply overriding the verb/method you're needing for a particular url.
NetKernel offers REST via Xml configuration files. Restlet offers REST with an entire new api and stack. I just can't see the benefits when the straight path (servlets) is the most simple, obvious and mature choice.
Adam
Also, Axis2 has in built support for REST.
But maybe Restlets in a Restlet container will be smaller?
Comparison of Restlet vs Servlet is a common question. First, let me say that Restlet started as an API built on top of the Servlet API, like Struts if you want. At some point the overlap didn't justify the dependency and prevented the usage of NIO and asynchronous requests processing. However, you are still able to deploy Restlet applications inside a standard Servlet container using a small adapter that we provide.
If you can afford a fresh start, you should consider the standalone deployment mode instead, using one of our production-ready server HTTP connectors (based on Jetty, AsyncWeb or Simple).
As for the need for a new API you can read the introduction paper and also this dedicated FAQ entry.
Of course, you can use any HTTP stack/API to build RESTful applications but you won't get a lot of help and guidance. For example, how do you handle content negotiation between multiple representations of a resource with the Servlet API? With the Restlet API, you just have to implement the Resource interface, and provide a result for the getVariants() method, then the framework will automatically select the best variant for you, based on the current client preferences!
Best regards,
Jerome