Re: URI Templates - optional variables?

Am 01.08.2007 um 10:58 schrieb Mike Schinkel:

> Stefan Eissing wrote:
>> 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}
>
> According to the spec as written, the equal sign would need to be URL
> encoded so your suggestion of putting many parameters into one  
> variable
> won't work.  And I think they made a really good call on that; it  
> really
> simplifies the spec and makes it very deterministic.

I am all for deterministic, always and under any circumstance.

However, I dare to say that your reading of the spec is wrong. The  
"=" would *not* need to be encoded.

<quote>
During substitution, the string value of a template variable MUST  
have any characters that do not match the reserved or unreserved  
rules (i.e., those characters not legal in URIs without percent  
encoding) percent-encoded, as per [RFC3986], section 2.1.
</quote>

"=" is a reserved char in 3986, section 2.2.

> [lots of good arguments and examples]
> If you say that the client can determine that {params} should be
> "a=1&b=2&c=3" then you are violating both URI opacity and the  
> hypermedia
> constraint of REST. You don't really want to do that, do you?

Whoa, that is just BS, pardon me language. Even in your proposed  
forms example, the forms specification would have to define the  
(obvious) connection between template parameter name and input field  
names. It could also define that all non-empty input fields go into  
the query part of the resulting url.  So this can be solved *outside*  
the uri template spec.

> P.S. I'm curious as to your objection to my proposal?  I know some  
> people
> approach specs with a desire to add tons of features and others  
> approach
> them from the perspective of doing their best to block features  
> getting into
> a spec, and there are good reasons for both approachs. That said,  
> and I
> don't mean to be disrespectful but your objections seems to me to be
> objection for objection sake.  Is that a case?

Well, well. With due respect: you experience that a lot?

I think that my suggestion to use RFC 3986 path resolution on uri  
template results is a valid proposal. And given the past discussion  
about zillions of special parameter substitution suggestions, I'd  
rather have a simple, deterministic uri template spec than the tower  
of bable rebuild.

--
Stefan Eissing

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

Received on Wednesday, 1 August 2007 09:37:39 UTC