Re: URI Templates - optional variables?

Am 31.07.2007 um 21:30 schrieb Mike Schinkel:
> Stefan Eissing wrote:
>> converter MUST perform path resolution as described in RFC
>> 3986 ch. 5.2.3 and 5.2.4. That will also stop some injections
>> of "." and ".." into URIs while saving the client from
>> worrying to much about double "/" and such.
>
> I read the spec but am one that still has trouble understanding  
> portions of
> a spec that do not include examples such as those. Which of the  
> following
> are you saying it should result in?
>
> A.) http://www.example.com/
> B.) http://www.example.com//

Clearly A. The path resolution will always make conversions such as:

//  ->  /
/./  ->  /
/a/../b -> /b

> usable. Imagine the following where most of the time all parameters  
> would be
> null:
>
> http://www.example.com/?a={a}&b={b}&c={c}&d={d}&e={e}&f={f}&g={g}
>
> Without optional parameters the URLs almost always look like this  
> (<ugh>):
>
> http://www.example.com/?a=&b=&c=&d=&e=&f=&g=
>
> Instead of, more approripately, like this (<smile>):
>
> http://www.example.com/
> http://www.example.com/?a=foo
> http://www.example.com/?c=bar
> http://www.example.com/?d=foo&f=bar

Clearly, such urls are better than the one with all empty params.  
Perhaps this can be solved outside the spec. Your example:

http://www.example.com/?a={a}&b={b}&c={c}&d={d}&e={e}&f={f}&g={g}

could also be transformed to the template

http://www.example.com/?{params}

The task to make usage elegant to an application could then be in the  
uri template resolver code. If you pass a hash/dictionary/map as  
value for "params", the resolver could build the query parameter itself.

--
Stefan Eissing

<green/>bytes GmbH
Hafenweg 16
D-48155 Münster
Germany
Amtsgericht Münster: HRB5782