Hi William, On Jan 9, 2008 11:30 AM, William Pietri <[EMAIL PROTECTED]> wrote: [...] > Hi! I'm just getting started with the Restlet framework, and have a few > questions. I'll start with one on trying to build web applications in a > RESTful way.
Welcome to the party. :-) [...] > I am going to build an Ajax-y web-app, which will naturally mix > traditional page rendering with API calls. Many of my resources will need > to be represented both ways. Ideally, I'd like to do this with one set of > URIs; duplicating everything under /api/ seems suboptimal to me. Depends on what you want to be able to do in terms of things like controlling access, segregating access of the two parties (i.e., segregating programmatic access to your service to particular servers (i.e., api.scissor.com)), etc. A potentially big issue is the ability to throttle access differently to different groups. For the rest of this reply, I'm going to ignore those issues and presume doing them together. > Given that, I'm having trouble creating resources using POST. Suppose I > POST a new order to > > http://example.com/order/ > > The server would then create the order, give it an order number, and tell > the client where to find it: > > http://example.com/order/1234567890 > > Then the client can look at the resource and display it to the user. > > If I'm dealing with an API, then I'd return a "201 Created" and put in a > Location header. The client could then go fetch that. For a browser, > though, I want them to go look at the order, so I'd be inclined to send a > 301 redirect to that same location. > > I can think of a few ways around this conflict, but I don't like any of > them all that much. So I'll just ask: what do you do when you want to > return one result code to an API, and another to a browser? One way to do this is to use different representations for the different types of clients. I.e., support the usual (x)html for the "human" web interface and a pure xml (or the current hype-child... json) for the programmatic clients. Then in your resource classes, check the media type requested and bundle up the different content and responses based thereon. I'm actually in the middle of writing this trick up for my REST presentation for SD West. :-) In your Resource sub-class's constructor, add the different media types that you support: getVariants().add ( new Variant (MediaType.TEXT_PLAIN) ); and then in the getRepresentation(Variant): public Representation getRepresentation (Variant variant) { MediaType mediaType = variant.getMediaType(); if (mediaType.equals (MediaType.TEXT_PLAIN)) { // Do your thing for this, set the response code that you want and then return the representation. } // Lather, rinse, repeat for each of your supported variants. getResponse().setStatus (Status.CLIENT_ERROR_NOT_ACCEPTABLE, "Sorry, unable to provide the requested " + "media type variant (" + mediaType + ")!"); return null; } Hope this helps, John
