In a real application, it is usually better to write high-level Resources than Restlets, though wiring in a Restlet as in the Foo.zip example is often the briefest way to return an HTTP response. Have a look at this tutorial, if you haven't already:
http://www.restlet.org/documentation/1.1/firstResource Resources are at a higher level of abstraction. A new instance of a Resource is created to handle each Request, which frees you from some thread safety concerns. Restlet instances are permanently wired in to your application, and can handle Requests from many threads, so they must be thread safe. By overriding methods like allowPost() to return true, the Resource signals what's allowed higher up the chain. Methods like represent() and acceptRepresentation() allow you to expose the representational details of your object, and let the Restlet API handle the rest of the connector infrastructure (magically coping with hard stuff like ETag assignment and dealing with conditional GETs in HTTP). There's no difference in server-side Restlet programming for a GWT client and a non-GWT client, so all the existing 1.1 documentation applies. On Thu, Sep 11, 2008 at 12:49 PM, Mark Petrovic <[EMAIL PROTECTED]>wrote: > Fantastic, Thierry. Thanks much. > Dumb question: how, or should, one integrate the notion of "allow > post"/"allow put", etc, in the TestServer code? > > Mark >
