Re: URI Template experience

References (the archive doesn't show the links):

   1. path-to: http://github.com/asplake/path-to/tree
   2. described_routes: http://github.com/asplake/described_routes/tree
   3. addressable: http://github.com/asplake/addressable/tree
   4. Partial template expansion in described_routes:
   http://positiveincline.com/?p=294
   5. Manifesto and roadmaps for described_routes and path-to:
   http://positiveincline.com/?p=213

Also a very noddy Delicious example here: http://positiveincline.com/?p=254,
slightly improved upon here from a Ruby perspective thanks to positional
parameters here: http://positiveincline.com/?p=285.

Regards,
Mike


2009/5/19 Michael Burrows <asplake@googlemail.com>

>
> [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 <http://github.com/asplake/path-to/tree>,
> and then described_routes<http://github.com/asplake/described_routes/tree>,
> 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 <http://github.com/asplake/addressable/tree> 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<http://positiveincline.com/?p=294> (including
> the comments) and Manifesto and roadmaps for described_routes and path-to<http://positiveincline.com/?p=213>.
>  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
>
>
>