W3C home > Mailing lists > Public > uri@w3.org > February 2010

Re: URI Template experience

From: Roy T. Fielding <fielding@gbiv.com>
Date: Thu, 25 Feb 2010 15:10:07 -0800
Cc: Mark Nottingham <mnot@mnot.net>, Joe Gregorio <joe@bitworking.org>, URI <uri@w3.org>
Message-Id: <C51876B2-BD4B-40B4-B792-04B46A64D107@gbiv.com>
To: mjb@asplake.co.uk
On Aug 23, 2009, at 3:23 AM, Mike Burrows wrote:

> Thanks again.  Couple of comments now that I've had a change to build the doc:
> 
> 1) It would be very useful to be able to specify that a variable is
> mandatory, to prevent invalid expansions such as
>    http://users/{userid}/settings
> to
>    http://users//settings
> (not to mention others that look less clearly invalid but are still
> not the intention of the template)
> 
> This will give much more reliable feedback to the client than a
> server-side validation ever could.  This can be achieved without
> changing the syntax simply by specifying that an error is raised by a
> Simple or Reserved substitution, if the variable has not been assigned
> and no default value is specified.
> 
> Nothing is lost with my proposal - this template:
>    http://users/{userid=}
> will expand in the unassigned case to be
>    http://users/
> 
> Others may have good reasons to propose additional syntax though.

I don't like the idea of adding conditions that cause errors
on the client.  Ideally, a valid template should always result
in a valid URI even if the client has no clue.  The server is
supposed to have provided the appropriate values and thus should
not find itself with a URI that it does not expect to handle.

> 2) Can (or should) the new syntax have a neat way (or any way at all!)
> to support things like optional file extensions?  Like them or loathe
> them they're important out there in the wild - try modeling a
> multi-format Rails application efficiently without them.
> 
> In the old syntax {-prefix|.|format} did the trick nicely; something
> like {.format} might be a good fit now (it's in the spirit of the new
> / operator) but perhaps it could be generalised.  Or did I miss a
> trick in the new syntax?

I think that makes sense -- I'll add it to the list.

....Roy
Received on Thursday, 25 February 2010 23:10:35 UTC

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