Re: URI Template experience

On 26 February 2010 00:10, Roy T. Fielding <fielding@gbiv.com> wrote:

> 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 <http://users/%7Buserid%7D/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=} <http://users/%7Buserid=%7D>
> > 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.
>


Um, don't the values come from the client?  As the spec stands the client
has no clue about which variables are mandatory and which are optional.  To
be honest though, I can live without this as I already hold externally the
information on whether variables are mandatory or optional.  I won't mention
it again, but it does still seem to me sensible change to make though.



> > 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.
>
>
Excellent, thanks, I'm already finding it very useful.  As per the examples
I sent yesterday, it could generalise to expansions on multiple variables,
just like the / operator does.



> ....Roy
>
>
Sorry, one last thing.  Not that I have a use case for reserved expansion,
but should it allow {var,+hello}, i.e it works as a per-variable modifier?
Achieving reliable comma-separation in the presence of optional variables
would be difficult otherwise.  And it is understood that there are
significant limits to what default values could be specified for reserved
expansion (I assume they're allowed, though there are no examples)?

Mike