Re: URI Template experience

[I'm not a member of this list - I'm responding to Joe's blog post, so  
apologies if this message doesn't thread properly]

I used URI Templates in a proof-of-concept that demonstrated scripting  
(in Ruby) and acceptance testing of a real-time Java-based component  
in the bond trading arena that previously had no HTTP interface.  I'm  
no longer with the firm, but the project was regarded as a success  
(others are building on it), and the idea of resource-oriented HTTP  
interfaces also gained traction internally.  Now on leave, I have  
built on the experience to prototype a metadata-driven Rubygem path- 
to, and then described_routes, which generates said data from Rails in  
JSON, YAML and XML.  I'm aware of one real-world Javascript client for  
the JSON data.

Ruby has excellent URI template support in the shape of Bob Aman's  
(sporkmonger's) addressable gem.  I've taken advantage of a recent  
feature which allows templates to be partially expanded, which in my  
case allows the generation of metadata specific to a resource  
instance, which in turn points the way to discovery via arbitrary  
landing sites, not just the application's root or some designated  
metadata link.  I find this interesting as it may offer convenient  
ways for client applications to find and follow hyperlinks that relate  
to arbitrary non-html-based representations.

I do use the prefix and join operators.  For example, typical Rails  
routes translate to paths like

    /parent/{parent_id}{-prefix|.|format}
    /parent/{parent_id}/child{-prefix|.|format}

where {format} is an optional parameter.  The {format} parameter makes  
it difficult to model this nicely in schemes that are strictly  
hierarchical and (more generally) there's merit I think in the  
indirection offered by having full URI templates.  I have argued that  
this reduces coupling.

The join operator is useful when modelling APIs that rely heavily on  
query parameters (e.g. Delicious).  I like being able to disregard  
whether a parameter goes into the path or the query.

A lot of this is covered in Partial template expansion in  
described_routes (including the comments) and Manifesto and roadmaps  
for described_routes and path-to.  The whole 3-4 week journey is  
covered extensively in earlier posts.

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 not interested personally in parsing.  Decent web frameworks do it  
already, and if clients need to do it there's probably something wrong  
somewhere.

Regards,
Mike
mjb@asplake.co.uk
http://positiveincline.com
http://twitter.com/asplake


> It's been a while since the URI Template draft has been updated, and
> in the interim
> there has been some implementation experience:
>
>    http://blog.springsource.com/2009/03/08/rest-in-spring-3-mvc/
>    http://code.google.com/p/uri-templates/wiki/Implementations
>
> In the intervening months two things have happened:
>
> 1. In all the URI Template examples I've seen, only the simplest  
> case {foo} has
>    even been shown.
>
> 2. I've been repeatedly asked about "going the other way", i.e.  
> parsing URIs
>    based on templates.
>
> This leads to two questions:
>
> 1. Are there any real-world uses of the more complex URI Templates, or
> is {foo} enough?
>
> 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?
>
>   Thanks,
>   -joe
>
> -- 
> Joe Gregorio        http://bitworking.org