Re: URI Template experience

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