Re: Content Negotation vs. Extensions

From: Dhanji R. Prasanna <>
Date: Thu, 26 Apr 2007 21:36:15 +1000

On 4/26/07, Paul Sandoz <> wrote:
> Stefan Tilkov wrote:
> > E.g. I could do a GET on to get the
> > default representation, say in HTML, and use
> > to get an XML representation.
> > Whether this is "good" or "bad" doesn't really matter IMO; it's going to
> > definitely a common approach. How do we address this?
> >
> Good question.

Yea good question =)

> @UriTemplate("{customer_id}")
> class Customer {


> @HttpMethod
> JSONObject getAsJSONResource() { ... }
> }

I really dont like this at all. It doesnt make clear what the resource names
are. I have to manually concatenate all the combinations (that exist or dont
exist on each method) in order to tell the resource names represented by
this *single* resource class.

Although i do like the way '_at_UriTemplates("", ".xml")' expresses things
> but could not think of anything better in the few minutes of thought
> about it.

If you meant "dont" like, im with you--I think its very ugly. =(

I suggest the following (rather straightforward) approach:

//resource at "default" name
public class PersonResource {

   Person getPerson() {

   @HttpMethod @Produces(TEXT_HTML)
   public Person get() { return getPerson(); }


//resource at alternate name
public class XmlPersonResource {
   @RsResource PersonResource res;

   @HttpMethod @Produces(TEXT_XML)
   public Person get() { return res.getPerson(); }


To me, this is a logical analog of the HTTP idiom: each resource name (in
our case "name-template") has its own resource backing it. Alternate
representations can delegate to the default resource impl (injected by the
runtime), but this is a trivial implementation detail.

So we would need a way to distinguish between path segments and non-path
> segments for HTTP methods that are marked as sub-resources, perhaps
> requiring things to being with a "/" ? (which just for URI
> template-based HTTP methods is a very easy fix to the implementation of
> the algorithm).

Such impositions seem arbitrary and intrusive; and are a bit subtle to learn
easily imo.
At first blush, I think your matcher could be made to work nicely with the
resource class-per-extension approach.