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.