Hi Dhanji,
In my emails on this thread i made an error and the matching
algorithm i described cannot 'join-up' URI templates that are to be
considered part of the same URI path segment. Sorry! Note that the
description/advantages of sub-resources as in the example i explained
still holds (reuse, polymorphism etc).
Sub-resources always require delineation with a '/' because the
runtime does not always know until it gets a concrete object what sub-
resources (if any) may follow, all the runtime knows is that there
may be sub-resources delineated with a '/'.
However, as you point out it is possible by other means, or more
generally one could use "{item}.{format}", but it is up to the
developer to do some work with the suffixes.
Paul.
On Apr 26, 2007, at 1:36 PM, Dhanji R. Prasanna wrote:
>
>
> 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.