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.)
> B.)

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:
> Without optional parameters the URLs almost always look like this  
> (<ugh>):
> Instead of, more approripately, like this (<smile>):

Clearly, such urls are better than the one with all empty params.  
Perhaps this can be solved outside the spec. Your example:{a}&b={b}&c={c}&d={d}&e={e}&f={f}&g={g}

could also be transformed to the template{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
Amtsgericht Münster: HRB5782

Received on Wednesday, 1 August 2007 07:27:22 UTC