dev@jsr311.java.net

Re: Content Negotation vs. Extensions

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

On 4/26/07, Paul Sandoz <Paul.Sandoz_at_sun.com> wrote:
>
> Stefan Tilkov wrote:
> > E.g. I could do a GET on http://example.org/customers/4711 to get the
> > default representation, say in HTML, and use
> > http://example.org/customers/4711.xml 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 {
>

<snip>

   @UriTemplate(".json")
> @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
@URITemplate("/peeps/{person_id}")
public class PersonResource {

   Person getPerson() {
       //...
   }

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

}

//resource at alternate name
@URITemplate("/peeps/{person_id}.xml")
public class XmlPersonResource {
   @RsResource PersonResource res;

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

//etc.


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.

Dhanji.