W3C home > Mailing lists > Public > uri@w3.org > May 2009

Re: URI Template experience

From: Bob Aman <bob@sporkmonger.com>
Date: Tue, 19 May 2009 12:35:01 -0400
Message-ID: <81c242240905190935g45254ce1m146721044d33749e@mail.gmail.com>
To: uri@w3.org
Cc: Michael Burrows <asplake@googlemail.com>, joe@bitworking.org
> Ruby has excellent URI template support in the shape of Bob Aman's (sporkmonger's) addressable gem.

Thanks.  :-)

> My conclusion therefore is to keep the more advanced features of URI Templates.  The examples (if they're intended as a test set) could do with beefing up - I contributed a couple of bug fixes to Addressable that weren't covered by them.  I did express regrets early on that URI templates didn't distinguish between optional and mandatory parameters, but I've dealt with that now in the surrounding metadata and it's no longer a concern.

I'm with Michael here.  Please keep the advanced features.  Just
because they only get used by a handful of people doesn't mean they're
not useful.  I suspect they're less used for a variety of reasons,
through no fault of the URI template spec.

Couple of factors:
* They're obviously harder to handle than the {foo} case for anyone
who's rolling their own URI template support.  This will be less of an
issue as library support improves.
* Frameworks and application developers have been moving towards
representing parameters like so: /{controller}/{action}/{id}/  Some
people even have gotten the impression that "pretty" URIs are what
REST is all about.  There is a non-trivial number of people who think
the presence of a query parameter is inherently unRESTful.  With this
kind of misunderstanding, it's not unreasonable to expect that the
{foo} case will continue to be dominant in the real world for quite
some time.
* URI templates for routing are only just starting to catch on.  I
just submitted a [small patch][1] (which was accepted) to the Sinatra
web framework that allows URI templates to be used for routing
purposes.  IMHO, the advanced features of URI templates are much more
useful in this scenario.  Well, aside from the neg and opt operators
anyways.  Right now my library throws an exception if you try to use
them in a route because you can't extract a canonical value for the
parameter.  (Note that neg and opt are still useful for simplifying
partial template expansion.)

I've put a HUGE amount of work into the Addressable library, and if
you haven't played with it yet and you're interested in my take on
what URI templates can be used for, you may want to take it for a
spin, even if you're not a Rubyist.

> 1. Are there any real-world uses of the more complex URI Templates, or
> is {foo} enough?

I can say, unequivocally, yes.  My current employer is making
extensive use of them for an internal application.  We have to
maintain several UIs to our application, including a Flex one.  We
send URI templates to the Flex UI so that it knows how to get the
right data out of our REST interfaces.  Sometimes a template needs to
get partially filled in before being passed to Flex, which was the
motivation for the partial evaluation algorithm.  (Essentially,
Template + Mapping -> Template instead of Template + Mapping -> URI.)

> 2. *If* the syntax is simplified to {foo} there is an opportunity to
> support the parsing
>    case, ala http://bitworking.org/projects/1812/wsgidispatcher.html
>     Is that of interest to anyone?

Yes, that's of interest, however, simplification is not really
necessary to support this use case.  See Addressable::Template.match.

I would be very interested, however, in seeing the reverse operation
of each operator actually specified.  Especially neg/opt, since it
bothers me to have to throw those exceptions due to undefined

I should probably note that a lot of the improvements I've made to
Addressable are still only available via source control.  So if you're
going to take a look, you want to grab a copy off of [GitHub][2].  The
test suite may also be of interest.  It's rather extensive.

Bob Aman

[1]: https://sinatra.lighthouseapp.com/projects/9779-sinatra/tickets/217
[2]: http://github.com/sporkmonger/addressable/tree/master
Received on Tuesday, 19 May 2009 19:31:50 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:25:13 UTC