URI Templates design experience

It's been a while since the URI Template draft has been updated, and in the interim there has been some implementation experience:

In the intervening months two things have happened:

In all the URI Template examples I've seen, only the simplest case {foo} has even been shown.
I've been repeatedly asked about "going the other way", i.e. parsing URIs based on templates.

This leads to two questions:

Are there any real-world uses of the more complex URI Templates, or is {foo} enough?
If the syntax is simplified to {foo} there is an opportunity to support the parsing case, ala WSGIDispatcher Is that of interest to anyone?

Feedback on the W3C URI mailing is appreciated.

I've had cases where a path needed to be extracted from a URI via a template. For example, http://example.org/namespace/this/is/a/path/to/something, where "/this/is/a/path/to/something" maps to the path of an item on disk. In this example, I was using RESTlet to parse a URI and to retrieve the path into a variable defined in the template. This is probably another common use case.

Posted by Dave Bordoley on 2009-05-18

I'm definitely a fan of going the other way, but then again, I'm responsible for this implementation( http://www.metanotion.net/software/urlmapper/ ), which is primarily for routing/dispatching in my web framework. I realize I'm a nobody doing their own Java framework built on top of servlets(and I haven't even released the whole framework on the web yet, or even finished it :) ), but I think its handy and declarative, and even find the limitations liberating.

A quick look showed all my template files just use the {foo} syntax and it does simplify parsing, but I also find that I'm relying on the default handling of the query string parameters by Jetty rather than writing those parameters into the template. Personally, I wouldn't mind a more complex spec, I just want to vote for a spec that supports both cases(parsing and generation of uri's).

Posted by Matt Estes on 2009-05-18

Microsoft also did an implementation of URI templates in .NET http://msdn.microsoft.com/en-us/library/bb675245.aspx Arnon

Posted by Arnon Rotem-Gal-Oz on 2009-05-19

I've only ever got around to implementing {foo} from the first draft. My plan was, and I guess still is, and perhaps always will be, to implement the rest when I need it..

Posted by Paul Annesley on 2009-05-20

Part of the issue may be that some of the more sophisticated examples are tricky to understand and (maybe?) malformed. On the URI Templates home page, clicking on either of the following examples causes the explain.cgi script to claim they are not valid URI templates:

http://www.google.com/notebook/feeds/{userID}{-prefix|/notebooks/|notebookID}{-opt|/-/|categories}{-listjoin|/|categories}?{-join|&|updated-min,updated-max,alt,start-index,max-results,entryID,orderby}
http://bitworking.org/news/{-listjoin|/|entrypath}

Posted by Ramon on 2009-05-21

We all know that Cool URIs don't change, specifically that the resources of a URI shouldn't change after it's published. So in my view, the notion of using URI templates to parse a URI is flawed. If I change the template, which governs a million resources, I don't want it to retroactively change the URIs of a million resources out there. That would just invite to massive link rot.

I believe that URI templates should be used to generate URIs at the time a resource is created, and that the URI is kept in some URI storage facility for the duration of the resource's life. Kind of like a file name occupies a slot in the file system for the lifetime of that file.

I feel this is the only way an owner of a domain can really own the URI space of their domain.

There are of course interesting edge cases like URIs that don't exist yet (e.g. the delicious tag 0rojfkneknide probably doesn't exist yet, so couldn't be in any URI lookup space) but since URIs (certain schemes at least) are hierarchical then the parent URI (e.g. delicious.com/tag/) should be "owned" by a resource which can be said to claim any URIs "beneath" this URI.

Dunno if any of this made any sense, but:

I don't want a two-way spec, since there's too many ways to get it wrong.
I'd also try to simplify the spec and simply require all substitutes to be pre-escaped wrt URI escaping, since you then can fall back to "all URIs are ASCII".
Rename "join" to "querystring" since that's really what it is, and its only real use case.
Perhaps even drop it, since ?foo={foo}&bar={bar} would work just as well as ?{-join|foo,bar}

Posted by Erik Mogensen on 2009-05-21

2009-05-18