> I see that I am in fact using the Simple connector, as per the FirstResource > tutorial, I went out of my way to put its jar on the classpath. This > configuration is what I meant by 'standalone server'.
I like Simple in concept, but I've had some not-so-wonderful experiences with it in practice. It also seems to be supported by a smallish team with limited resources. Jetty's been uniformly wonderful for us in production -- we were using it for embedded apps before we started working with Restlet, and I recommend it as both a Servlet and a Restlet container. But Jerome runs the Restlet and Noelios sites on Simple, so everyone's experiences do not match mine :-) > I'm just making this up as I go along, but I'm not opposed to learning > something in the process :-) So I had envisioned that my Restlet > application would have two logical clients: 1) the browser for some > requests, and 2) embedded Ajax for others. And I'm starting to wonder if I > can reconcile that bipartite model with a stateless server. It is challenging, but can be done. Let's see. The classic example of something very hard to implement without *some* server side state is an e-commerce shopping cart. There are a handful of examples on the web of a "purely RESTful shopping cart," but they tend to be a bit odd -- either in implementation or UI -- compared to the experience that folks have come to expect from something like Amazon.com. For example, one has you dragging things between frames, and if you click the Back button too many times, you lose your cart. Since odd experiences don't usually translate to sales, 99% or more of sites that provide a shopping cart, use some server side state tied to a browser identity cookie. But one way to RESTify this model, without changing it completely, is to deconstruct the idea of the "session" a bit. Instead of having one generalized server-side bag of state (the JSP/Servlet style HttpSession), which can only be accessed using server-side code, the client can use RESTful operations to create a needed resource on the server (e.g. a ShoppingCartResource); then these resources may be exposed back to the creator using RESTful patterns. This hypothetical ShoppingCartResource would have a URI and variant representations that can be PUT, GET, etc., including perhaps an HTML representation that is the full decorated "web page" representation for dumb-browser use, and a JSON or XML representation more suitable for AJAX interaction. It could be authenticated in some way, so that its contents were only mutable by the original creator (identified by a cookie or HTTP Basic, perhaps). Now you have your shopping cart abstracted in a way that you can work with it on the server side using internal requests (we use Restlet riap:// calls), OR work with it on the client side using an Applet, Flex/Flash RIA, GWT, or AJAX application. The philosophy behind all this is a bit head-twisting, but once I did it this way a few times, I never ever ever EVER wanted to go back to the "old" way! It is more up front work to decide I need a class of server-side resource, and work through how to handle it, rights and responsibilities, side effects of operations, etc. But, once I've done that, I'm DONE with the server architecture ... and the resource integrates with any kind of Web-based client, regardless of platform, language, etc. With the Servlet session model, it's so easy to throw things in the session bag, but then I need to invent ways of getting them out every time I want to move processing to the client. Net effect: with sessions, I don't wanna move any processing to the client. P.S. Since Restlet doesn't do it on its own yet, here's my browser identity cookie generator: http://gogoego.googlecode.com/svn/trunk/modules/RestletFoundation/src/com/solertium/container/CookieUtility.java - Rob
