Re: URI Templates - optional variables?

On 10/15/07, Roy T. Fielding <fielding@gbiv.com> wrote:
> I am struggling to think of a use case for arrays in real practice.
> I could understand modifying join such that it treats single variables
> with array values the same as multiple variables with single values,
> e.g,
>
>    http://example.org/sausage?{+,|condiments} =
>    http://example.org/sausage?condiments=tomato%20sauce,chutney,relish
>
> but I can't think of a case where I would need that for a web service.
> Also, how does the reader of the template know that the variable is
> supposed to be an array?

The 'listjoin' operator, <&>, is the part of my proposal that I
feel the least comfortable with, as it ends up introducing 'types'
into the grammar. The parsing is simple enough that you
don't need a type declaration since only 'listjoin' takes
a variable of type 'list', and you could carry that type information
along and flag ambiguous/invalid templates such as:

    {&/|a}{</|a}

But there is a need for something that allows me to
create templates for two situations I put in the proposal, my
own blog:


   URI Template
       http://bitworking.org/news/{&/id}
   Template Variable(s)
       id := ['RESTLog_Specification']
   URI
       http://bitworking.org/news/RESTLog_Specification

   Template Variable(s)
       id := ['240', 'Newsqueak']
   URI
       http://bitworking.org/news/240/Newsqueak

and the GData boolean logic:

    URI Template
          {?/-/:categories}{|/:categories}
    Template Vars
          categories = ["A|-B", "-C"]
    URI
            /-/A%7C-B/-C

If there are other ways to achieve the same result
without resorting to lists I'd love to avoid them
if possible.

> An alternative would be to go the perl direction and add a form
> of type annotation to the variable names, as in
>
>     http://example.org/checkaddress{,&|name,@address}
>
> but variable types might be a slope too slippery.

Types and type decorators? I shudder at the thought :)

   -joe

-- 
Joe Gregorio        http://bitworking.org

Received on Tuesday, 16 October 2007 05:30:41 UTC