Re: Platonic URIs

From: Paul Sandoz <Paul.Sandoz_at_Sun.COM>
Date: Tue, 25 Sep 2007 13:05:23 +0200

Marc Hadley wrote:
> (iii) We could consider including adding some convention-driven support
> to the UriTemplate annotation. E.g.:
> @UriTemplate(value="{id}" extentions=true)
> The above could surface a fixed-name URI template variable for any
> supplied extension so that for "foo.xml" you'd get UriParam("id")==foo,
> UriParam("extension")==xml.

I am leaning towards this approach.

Say we have these URI templates:


and we would like to support the following URIs from these templates:


I don't think it makes sense to support:


The suffices only makes sense on last path segment of the URI.

Off the top of my head this means we have the following regular
expressions (in order of matching precedence):


It may be useful to also specify such functionality at the level of the
web application such that one does not have to modify code.

We also need to make sure this works correctly when using the
limited=false option. For this template:

   @UriTemplate(value="/collection/{id}", limited=false, extentions=true)

We can have the following regular expressions (in order of precedence):


which allows us to have the following URIs:


Is this desirable? Or should we make limited and extentions mutually

In any case i think it should be fairly easy to augment the existing
algorithm with such behaviour be it per-application or per template and
consistently with "limited".


> GET /foo.xml
> Accept: */*
> is internally treated as if it were:
> GET /foo
> Accept: application/xml
> If we went this route we'd need to define a set of default mapping rules
> and probably some means to extend or modify the default set.
> What do folks think, are (i) and (ii) sufficient or are you interested
> in something along the lines of (iii) ? Perhaps there are other
> approaches we didn't consider ?
> Thanks,
> Marc.
> [1]
> [2]
> [3]
> ---
> Marc Hadley <marc.hadley at>
> CTO Office, Sun Microsystems.
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

| ? + ? = To question
    Paul Sandoz