As a third party kibitzer ... I feel like saying "Restlet vs. Servlet" at all is a bit semantically inadmissible. It's not an "or" operation. You can run Restlet with, without, in, outside, talking to, or being talked to by Servlet. The scope of the javax.servlet API is intentionally narrower; all it does is model REST-style Uniform message passing (service(request,response)) for the purpose of writing server code.
The Restlet framework adds a whole new abstraction layer specifically for modeling REST applications. With this, much or most application work can be done with higher-level Representations that are separated nicely from the service(request, response) paradigm. Both client and server can interact with the same Representation objects -- and indeed the same Uniform message layer -- whether or not any Servlets are involved in the process. On the "I/O agnostic" topic specifically, this separation of concerns becomes very interesting now as we explore things like asynchronous processing in the Restlet API. We can add mechanisms for things like callbacks -- things not even remotely modeled in the Servlet API -- that affect the message passing aspects in dramatic ways, without Representations, or in many cases even Resources, having to be aware of the change. NIO can make an HTTP connector more scalable at dispatching calls to Servlets -- obviously both Restlet and Servlet run on top of Jetty, MINA, and Grizzly NIO connectors, to name a few -- but the Servlet API does not do anything particularly interesting to expose non-blocking/asynchronous design advantages. If it did/when it does, Servlet authors will need to do refactoring to take advantage of it. With a more separated API like Restlet, it is easier for major design revolutions to take place in the I/O layer -- pluggably and optionally -- while the bulk of the application remains stable. At my company, before we discovered Restlet, we wrote a lot of this SoC ourselves -- trivial Servlets that interacted with Resource and Representation objects -- but our code was pretty much tied to J2EE containers, because there was just too much plumbing in Servlet that we didn't want to re-create in a more abstract way. After porting this all to Restlet, we find ourselves able to run the same applications online, offline, with or without a J2EE container, and have a nascent ability to do so in transcoded environments like GWT. I feel sometimes like we need to get Duke out of retirement to hop around and say "Write Once, Run Anywhere ..." That is really how it feels. - R On 2/5/08, jbarciela jbarciela <[EMAIL PROTECTED]> wrote: > > Now, are you saying there that there is something conceptual that > prevents Servlets to use NIO? (apart from possible implementation > details in particular servers like Tomcat) > If that's true, then how should we interpret statements like "Jetty > can use NIO" or "Glassfish can use NIO" ? > > Please notice that I don't intend to start a confrontation of the "I > say they say" kind, only looking for enlihgtment >
