Re: URI Template: expanding lists

On Nov 6, 2009, at 11:29 AM, Roy T. Fielding wrote:

> On Nov 5, 2009, at 10:52 PM, Bob Aman wrote:
> 
>>> [Comment on the URI Template working draft]
>>> 
>>> Is there any particular reason why the current draft suggests that
>>> variables typed as lists (marked with @) be expanded so that the
>>> variable name is followed by a generated numbering?
>>> 
>>> The numbering scheme seems quite odd and specific (1-based with first
>>> item unnumbered).
>>> 
>>> For example, in the case of the ? operator:
>>> 
>>> {?@list}  ?list=val1&list2=val2&list3=val3
>>> 
>>> Why not simply expand it as:
>>> 
>>>  ?list=val1&list=val2&list=val3
>>> 
>>> This would still be a perfectly valid sequence of query parameters.
>>> Or am I missing something obvious?
>> 
>> I think the obvious objection is that many web frameworks (php, rails,
>> app engine, etc) make the assumption that query parameter keys are
>> unique, so method calls like `request.params["list"]` would probably
>> return `val3` with no means of obtaining the array order or other
>> values in the array without parsing the request URI manually.  That
>> said, I don't think the obvious objection is a good reason to choose
>> what strikes me as the slightly less elegant option, and I would much
>> prefer your expansion to the current one.  URI templates aren't
>> necessary to the function of every web application, frameworks can
>> slowly adapt, and in the meantime, manually parsing the URI when
>> necessary is fine with me.
> 
> Yes, it matches the obvious limitation in HTML and all of the
> libraries that pre-parse query parameters into hash tables.
> The names must be unique.  More importantly, something like
> 
>   form.cgi{?name,@address}
> 
> is such a common idiom that I figured it was worth capturing
> in a short form.  Almost all examples I've seen using that
> kind of form use address, address2, address3 as the names.
> 
> However, I don't think this is a necessary feature for
> uri-templates, so we could just remove it if folks disagree.

FWIW, I removed that feature in favor of indicating more
complicated expansions with the explode modifiers and
external profiles.  Now lists should (eventually) look like

  {?list}           ?list=val1,val2,val3
  {?list*}          ?list=val1&list=val2&list=val3
  {?list+}          ?list.1=val1&list.2=val2&list.3=val3

though I don't expect them to be used as much as

   /mapper{?address*}

or

   /directions{?from+,to+}

where the variables are replaced by structured address
components according to some external profile.

....Roy

Received on Friday, 26 February 2010 02:30:06 UTC