Loading ...
Sorry, an error occurred while loading the content.

Re-using information fields for queries in REST

Expand Messages
  • dorchard100
    Hey all, I was wondering about the best way to RESTfully model information retrievals versus queries in REST. Imagine an Artist structure with name, genre,
    Message 1 of 23 , Jun 1, 2004
    • 0 Attachment
      Hey all,

      I was wondering about the best way to RESTfully model information
      retrievals versus queries in REST. Imagine an Artist structure with
      name, genre, albums, rating, etc. I want to both search for Artists
      that approximate the name or albums, or exactly match a genre or
      rating. As well, I want to retrieve a given Artist's information.

      The retrieval is easy, with something like GET /Artist?
      name=thieverycorp retrieving the structure.

      But then if want to do a search, I was thinking the best rest way of
      modeling is to make a Query structure that contains all the Artist
      queryable information, maybe it's even the same type, and then have
      an ArtistList resource. Then I could say that any of the ArtistQuery
      fields can be put in the URI, ie
      GET /ArtistList?name=thieverycorp or GET /ArtistList?albums=blue.

      I can't see a way of using the same URI base for both retrievals and
      queries without doing some funky parameters in the URI. There's a
      variety of other techniques, like appending the requested return type
      (GET /Artist?name=thieverycorp&type=ArtistList), the number of
      results to return (GET /Artist?name=thieverycorp&rows=1), etc. but
      they all seem a bit .... goofy.

      Any help on the best way to model this would be appreciated. I'm
      pretty sure this is almost an FAQ kind of question, so even a pointer
      would be great.

      Thanks,
      Dave Orchard
    • Walden Mathews
      ... From: dorchard100 To: Sent: Tuesday, June 01, 2004 1:33 PM Subject: [rest-discuss] Re-using
      Message 2 of 23 , Jun 1, 2004
      • 0 Attachment
        ----- Original Message -----
        From: "dorchard100" <orchard@...>
        To: <rest-discuss@yahoogroups.com>
        Sent: Tuesday, June 01, 2004 1:33 PM
        Subject: [rest-discuss] Re-using information fields for queries in REST


        | Hey all,
        |
        | I was wondering about the best way to RESTfully model information
        | retrievals versus queries in REST. Imagine an Artist structure with
        | name, genre, albums, rating, etc. I want to both search for Artists
        | that approximate the name or albums, or exactly match a genre or
        | rating. As well, I want to retrieve a given Artist's information.
        |
        | The retrieval is easy, with something like GET /Artist?
        | name=thieverycorp retrieving the structure.

        That looks more like a collection or subset to me. A single
        artist resource might be more like /Artist/123. An important
        question is: how does the client discover that URI? The "hyptertext
        engine" constraint of REST really wants it to be discovered, not
        fabricated by client as a parameter list.


        |
        | But then if want to do a search, I was thinking the best rest way of
        | modeling is to make a Query structure that contains all the Artist
        | queryable information, maybe it's even the same type, and then have
        | an ArtistList resource. Then I could say that any of the ArtistQuery
        | fields can be put in the URI, ie
        | GET /ArtistList?name=thieverycorp or GET /ArtistList?albums=blue.

        I would have called it /Artists?prop=value,..., but that's just
        naming preference.


        |
        | I can't see a way of using the same URI base for both retrievals and
        | queries without doing some funky parameters in the URI.

        URI's are cheap, and so then are URI bases. Why the need
        for such economy?

        There's a
        | variety of other techniques, like appending the requested return type
        | (GET /Artist?name=thieverycorp&type=ArtistList), the number of
        | results to return (GET /Artist?name=thieverycorp&rows=1), etc. but
        | they all seem a bit .... goofy.

        All stemming from a false sense of URI conservation, right?

        If your application really needs to hide the distinction between
        a single resource and a collection of that resource "type",
        then you could try an Alloy trick: treat instances as singleton
        sets.

        That would mean there are only queries, no retrievals (to use
        your lingo), and when a query returns a single result, blow right
        past the list representation to the individual. I don't know how
        RESTful or unRESTful that would be. I suspect it's neither.

        |
        | Any help on the best way to model this would be appreciated. I'm
        | pretty sure this is almost an FAQ kind of question, so even a pointer
        | would be great.
        |
        | Thanks,
        | Dave Orchard


        Walden
      • Roy T. Fielding
        Hi Dave, The best way is to have the query do just that -- present a list of query results. If you actually want it to direct the client to a single match,
        Message 3 of 23 , Jun 1, 2004
        • 0 Attachment
          Hi Dave,

          The best way is to have the query do just that -- present a list
          of query results. If you actually want it to direct the client to
          a single match, then send a redirect to that match. The resources
          themselves should be independently named from any query that you do,
          even if that means simply redirecting them to something dull like

          /Artist/id/12345678

          ....Roy
        • David Orchard
          ... Why is discovery of a particular URI better than discovery of the construction technique for a URI? This argues that HTML FORM GETs are a bad way of
          Message 4 of 23 , Jun 1, 2004
          • 0 Attachment
            > -----Original Message-----
            > From: Walden Mathews [mailto:walden@...]
            > | I was wondering about the best way to RESTfully model information
            > | retrievals versus queries in REST. Imagine an Artist
            > structure with
            > | name, genre, albums, rating, etc. I want to both search
            > for Artists
            > | that approximate the name or albums, or exactly match a genre or
            > | rating. As well, I want to retrieve a given Artist's information.
            > |
            > | The retrieval is easy, with something like GET /Artist?
            > | name=thieverycorp retrieving the structure.
            >
            > That looks more like a collection or subset to me. A single
            > artist resource might be more like /Artist/123. An important
            > question is: how does the client discover that URI? The "hyptertext
            > engine" constraint of REST really wants it to be discovered, not
            > fabricated by client as a parameter list.

            Why is discovery of a particular URI "better" than discovery of the construction technique for a URI? This argues that HTML FORM GETs are a bad way of creating URIs because they are fabricated.

            Cheers,
            Dave
          • Seairth Jacobs
            ... Suppose you defined the semantics of the query response format to provide such constraints/rules necessary to construct URIs. As long as the client
            Message 5 of 23 , Jun 1, 2004
            • 0 Attachment
              "David Orchard" wrote:
              -----Original Message-----
              From: Walden Mathews [mailto:walden@...]
              
              That looks more like a collection or subset to me.  A single
              artist resource might be more like /Artist/123.  An important
              question is: how does the client discover that URI?  The "hyptertext
              engine" constraint of REST really wants it to be discovered, not
              fabricated by client as a parameter list.
                  
              Why is discovery of a particular URI "better" than discovery of the construction technique for a URI?  This argues that HTML FORM GETs are a bad way of creating URIs because they are fabricated.
                
              Suppose you defined the semantics of the query response format to provide such constraints/rules necessary to construct URIs.  As long as the client understands the semantics of the format, you are basically where HTML forms are.  However, just listing the URIs themselves would be much more straight forward.  The URI is an opaque identifier.  As such, the client can stay dumb and loosely coupled.  If, at some later time, you should choose to change the URI construction (say from /artist/123 to /artist/tu123 or /a23423992359652), the client continues working unchanged.  The constructed URI approach, on the other hand, would be brittle.  You would either need to construct your URIs in a backward-compatible manner or require the clients to learn the new construction rules, neither of which are a very desirable choice.

              Suppose you want to reference artists on another site that uses an entirely different URI format.  Are you going to reverse-engineer those URIs and add yet more semantics to the query response format for those URIs?

              Also, there's a propensity for humans to see patterns in structures.  URIs are often such a structure.  I agree that a person seeing /artist/123 may be inclined to try artist/124.  However, I think people are more inclined to see /artist?id=123 and try /artist?id=124.  The moment you tell people that there is a pattern, they expect the pattern.  You can't stop people from seeing patterns where there may not be any, but you can certainly stop from telling people there is a pattern where you know there is not one.

              --
              Seairth Jacobs

            • Roy T. Fielding
              ... Caching. If you already have the information for that artist, why should you be forced to download it again? Often, the reason is because the resource
              Message 6 of 23 , Jun 1, 2004
              • 0 Attachment
                > Why is discovery of a particular URI "better" than discovery of the
                > construction technique for a URI? This argues that HTML FORM GETs are
                > a bad way of creating URIs because they are fabricated.

                Caching. If you already have the information for that artist,
                why should you be forced to download it again? Often, the reason
                is because the resource provider just assumes every access is a
                query by a new user on a home PC with broadband, because that is
                the only way they have ever tested their own site.

                The query URI is still a valid identifier for the query -- it just
                isn't as useful, alone, for enhancing scalability. A redirection
                allows an infinite number of queries to be redirected to a finite
                number of resources, each of which can be cached. [Note: special
                purpose caches can be created on the server-side for handling
                common queries, as is done by Google and big e-commerce sites, but
                that only improves back-end performance.]

                Anyway, we are talking about resource discovery over arbitrary
                data categories, and hence non-hierarchical in nature. There is
                nothing wrong with telling the client how it can form URI's,
                assuming that such a function doesn't change much over time.
                Again, for cache reasons, I prefer methods of telling the client
                to use the template

                http://example.com/quotes/${exchange}/${symbol}

                rather than the template

                http://example.com/quotes?market=${exchange}&symbol=${symbol}

                There is nothing stopping WSDL-like technology from defining
                both of these mechanisms.

                ....Roy
              • David Orchard
                Gotcha on the use of hierarchy rather than flat where appropriate. ... ... Hey, now there s an idea. Maybe even official WSDL technology... Cheers,
                Message 7 of 23 , Jun 1, 2004
                • 0 Attachment
                  Gotcha on the use of hierarchy rather than flat where appropriate.

                  > -----Original Message-----
                  > From: Roy T. Fielding [mailto:fielding@...]

                  <snip/>
                  > Anyway, we are talking about resource discovery over arbitrary
                  > data categories, and hence non-hierarchical in nature. There is
                  > nothing wrong with telling the client how it can form URI's,
                  > assuming that such a function doesn't change much over time.
                  > Again, for cache reasons, I prefer methods of telling the client
                  > to use the template
                  >
                  > http://example.com/quotes/${exchange}/${symbol}
                  >
                  > rather than the template
                  >
                  > http://example.com/quotes?market=${exchange}&symbol=${symbol}
                  >
                  > There is nothing stopping WSDL-like technology from defining
                  > both of these mechanisms.
                  >
                  > ....Roy
                  >

                  Hey, now there's an idea. Maybe even official WSDL technology...

                  Cheers,
                  Dave
                • David Orchard
                  I don t like the idea of keeping the URI construction opaque from the client because I don t want the extra round trip to get the list. And I think it s too
                  Message 8 of 23 , Jun 1, 2004
                  • 0 Attachment
                    I don't like the idea of keeping the URI construction opaque from the client because I don't want the extra round trip to get the list.  And I think it's too network/compute intensive to get a complete list at the client and then apply the filter/query to get the right matches. 
                     
                    And your solution doesn't help the version problem.  If the URI changes, it doesn't matter whether the algorithm changes or not, backwards compat still has to either be granted or lost.  If there isn't backwards compat, the client either has to get the new URI list or the new algorithm, and I think propagating the algorithm is fine.  Just like getting a new form page if somebody happens to be editing a form and the URI construction changes right in the middle.
                     
                    I have not a problem at all with relative URIs being not portable across authorities.  It's up to each authority to define and describe it's URI construction algorithm if it wants to expose one to a client.  Re-use of relative URIs across domains falls way outside the 80/20 point for the app I've been talking about.
                     
                    Cheers,
                    Dave
                    -----Original Message-----
                    From: Seairth Jacobs [mailto:seairth@...]
                    Sent: Tuesday, June 01, 2004 4:54 PM
                    To: rest-discuss
                    Subject: Re: [rest-discuss] Re-using information fields for queries in REST

                    "David Orchard" wrote:
                    -----Original Message-----
                    From: Walden Mathews [mailto:walden@...]
                    
                    That looks more like a collection or subset to me.  A single
                    artist resource might be more like /Artist/123.  An important
                    question is: how does the client discover that URI?  The "hyptertext
                    engine" constraint of REST really wants it to be discovered, not
                    fabricated by client as a parameter list.
                        
                    Why is discovery of a particular URI "better" than discovery of the construction technique for a URI?  This argues that HTML FORM GETs are a bad way of creating URIs because they are fabricated.
                      
                    Suppose you defined the semantics of the query response format to provide such constraints/rules necessary to construct URIs.  As long as the client understands the semantics of the format, you are basically where HTML forms are.  However, just listing the URIs themselves would be much more straight forward.  The URI is an opaque identifier.  As such, the client can stay dumb and loosely coupled.  If, at some later time, you should choose to change the URI construction (say from /artist/123 to /artist/tu123 or /a23423992359652), the client continues working unchanged.  The constructed URI approach, on the other hand, would be brittle.  You would either need to construct your URIs in a backward-compatible manner or require the clients to learn the new construction rules, neither of which are a very desirable choice.

                    Suppose you want to reference artists on another site that uses an entirely different URI format.  Are you going to reverse-engineer those URIs and add yet more semantics to the query response format for those URIs?

                    Also, there's a propensity for humans to see patterns in structures.  URIs are often such a structure.  I agree that a person seeing /artist/123 may be inclined to try artist/124.  However, I think people are more inclined to see /artist?id=123 and try /artist?id=124.  The moment you tell people that there is a pattern, they expect the pattern.  You can't stop people from seeing patterns where there may not be any, but you can certainly stop from telling people there is a pattern where you know there is not one.

                    --
                    Seairth Jacobs


                  • Mark Baker
                    ... *groan* Ok, sure, *now* you support my make WSDL more form-like suggestions. 8-) The new HTTP binding goes further in this direction, but still falls
                    Message 9 of 23 , Jun 1, 2004
                    • 0 Attachment
                      On Tue, Jun 01, 2004 at 05:47:54PM -0700, David Orchard wrote:
                      > Gotcha on the use of hierarchy rather than flat where appropriate.
                      >
                      > > -----Original Message-----
                      > > From: Roy T. Fielding [mailto:fielding@...]
                      >
                      > <snip/>
                      > > Anyway, we are talking about resource discovery over arbitrary
                      > > data categories, and hence non-hierarchical in nature. There is
                      > > nothing wrong with telling the client how it can form URI's,
                      > > assuming that such a function doesn't change much over time.
                      > > Again, for cache reasons, I prefer methods of telling the client
                      > > to use the template
                      > >
                      > > http://example.com/quotes/${exchange}/${symbol}
                      > >
                      > > rather than the template
                      > >
                      > > http://example.com/quotes?market=${exchange}&symbol=${symbol}
                      > >
                      > > There is nothing stopping WSDL-like technology from defining
                      > > both of these mechanisms.
                      > >
                      > > ....Roy
                      > >
                      >
                      > Hey, now there's an idea. Maybe even official WSDL technology...

                      *groan* Ok, sure, *now* you support my "make WSDL more form-like"
                      suggestions. 8-)

                      The new HTTP binding goes further in this direction, but still falls
                      short largely because it bumps up against the *very* different demands
                      of a forms language compared with an interface description language.

                      I'd personally prefer to start over with a forms language, which is
                      why I created RDF Forms; http://www.markbaker.ca/2003/05/RDF-Forms/ .
                      But it has a bit of legacy in its support of www-form-urlencoded
                      serializations for POST bodies and URIs largely because that's what
                      server APIs easily support and it's what I used at work. But I'd love
                      to get a more general generative naming language in there that could
                      support hierarchy as Roy describes.

                      Mark.
                      --
                      Mark Baker. Ottawa, Ontario, CANADA. http://www.markbaker.ca
                    • S. Mike Dierken
                      ... Well, let s start building one. Strawman01
                      Message 10 of 23 , Jun 1, 2004
                      • 0 Attachment
                        > But I'd love
                        > to get a more general generative naming language in there that could
                        > support hierarchy as Roy describes.

                        Well, let's start building one.

                        Strawman01
                        <!-- provide the URI pattern to use -->
                        <form resource="http://example.com/quotes/${exchange}/${symbol}"
                        method='get'>
                        <input name='exchange' type='text' />
                        <input name='symbol' type='text' />
                        </form>

                        Strawman02
                        <!-- provide the URI pattern to use, plus a 'class' attribute to indicate
                        the meaning of the input data - this allows a spider to discover all the
                        services which accept some form of data (like US zip code, telephone number,
                        etc) -->
                        <form resource="http://example.com/quotes/${exchange}/${symbol}"
                        method='get'>
                        <input name='exchange' type='text' class='stock.exchange' />
                        <input name='symbol' type='text' class='security.symbol' />
                        </form>
                      • David Orchard
                        I ve been looking at how map an xml tree into the path and same depth params into the forms, ala
                        Message 11 of 23 , Jun 1, 2004
                        • 0 Attachment
                          I've been looking at how map an xml tree into the path and same depth
                          params into the forms, ala
                          <Music><Artist><Name>ThieveryCorp</Name><Rating>5</Rating></Artist></Mus
                          ic>

                          gets mapped into something like GET /Music/Artist?Name=ThieveryCorp and
                          GET /Music/Artist/Rating?Name=ThieveryCorp

                          Mixed ns are a pain, but if you adopt the convention that the ns decls
                          are somehow in the algorithm, then it gets a little bit more managable.

                          Cheers,
                          Dave

                          > -----Original Message-----
                          > From: Mark Baker [mailto:distobj@...]
                          > Sent: Tuesday, June 01, 2004 8:38 PM
                          > To: David Orchard
                          > Cc: rest-discuss@yahoogroups.com
                          > Subject: Re: [rest-discuss] Re-using information fields for queries in
                          > REST
                          >
                          >
                          > On Tue, Jun 01, 2004 at 05:47:54PM -0700, David Orchard wrote:
                          > > Gotcha on the use of hierarchy rather than flat where appropriate.
                          > >
                          > > > -----Original Message-----
                          > > > From: Roy T. Fielding [mailto:fielding@...]
                          > >
                          > > <snip/>
                          > > > Anyway, we are talking about resource discovery over arbitrary
                          > > > data categories, and hence non-hierarchical in nature. There is
                          > > > nothing wrong with telling the client how it can form URI's,
                          > > > assuming that such a function doesn't change much over time.
                          > > > Again, for cache reasons, I prefer methods of telling the client
                          > > > to use the template
                          > > >
                          > > > http://example.com/quotes/${exchange}/${symbol}
                          > > >
                          > > > rather than the template
                          > > >
                          > > > http://example.com/quotes?market=${exchange}&symbol=${symbol}
                          > > >
                          > > > There is nothing stopping WSDL-like technology from defining
                          > > > both of these mechanisms.
                          > > >
                          > > > ....Roy
                          > > >
                          > >
                          > > Hey, now there's an idea. Maybe even official WSDL technology...
                          >
                          > *groan* Ok, sure, *now* you support my "make WSDL more form-like"
                          > suggestions. 8-)
                          >
                          > The new HTTP binding goes further in this direction, but still falls
                          > short largely because it bumps up against the *very* different demands
                          > of a forms language compared with an interface description language.
                          >
                          > I'd personally prefer to start over with a forms language, which is
                          > why I created RDF Forms; http://www.markbaker.ca/2003/05/RDF-Forms/ .
                          > But it has a bit of legacy in its support of www-form-urlencoded
                          > serializations for POST bodies and URIs largely because that's what
                          > server APIs easily support and it's what I used at work. But I'd love
                          > to get a more general generative naming language in there that could
                          > support hierarchy as Roy describes.
                          >
                          > Mark.
                          > --
                          > Mark Baker. Ottawa, Ontario, CANADA. http://www.markbaker.ca
                        • thompsonbry
                          This sounds very relevant to how XForms could use GET. I am assuming that we want the stronger constraint of bookmarkability, right? Not just caching? So that
                          Message 12 of 23 , Jun 2, 2004
                          • 0 Attachment
                            This sounds very relevant to how XForms could use GET.

                            I am assuming that we want the stronger constraint of
                            bookmarkability, right? Not just caching?

                            So that we are not talking about GET with a request body (which could
                            perhaps be made cachable, e.g., using "Vary") but a means of mapping
                            an XML document (which could be just a property set for flat vs
                            hierarchical addressing) into a URI.

                            E.g., a "application/iriencoded-xml" MIME type.

                            -bryan

                            --- In rest-discuss@yahoogroups.com, "David Orchard" <orchard@p...>
                            wrote:
                            > I've been looking at how map an xml tree into the path and same
                            depth
                            > params into the forms, ala
                            >
                            <Music><Artist><Name>ThieveryCorp</Name><Rating>5</Rating></Artist></M
                            us
                            > ic>
                            >
                            > gets mapped into something like GET /Music/Artist?Name=ThieveryCorp
                            and
                            > GET /Music/Artist/Rating?Name=ThieveryCorp
                            >
                            > Mixed ns are a pain, but if you adopt the convention that the ns
                            decls
                            > are somehow in the algorithm, then it gets a little bit more
                            managable.
                            >
                            > Cheers,
                            > Dave
                            >
                            > > -----Original Message-----
                            > > From: Mark Baker [mailto:distobj@a...]
                            > > Sent: Tuesday, June 01, 2004 8:38 PM
                            > > To: David Orchard
                            > > Cc: rest-discuss@yahoogroups.com
                            > > Subject: Re: [rest-discuss] Re-using information fields for
                            queries in
                            > > REST
                            > >
                            > >
                            > > On Tue, Jun 01, 2004 at 05:47:54PM -0700, David Orchard wrote:
                            > > > Gotcha on the use of hierarchy rather than flat where
                            appropriate.
                            > > >
                            > > > > -----Original Message-----
                            > > > > From: Roy T. Fielding [mailto:fielding@g...]
                            > > >
                            > > > <snip/>
                            > > > > Anyway, we are talking about resource discovery over arbitrary
                            > > > > data categories, and hence non-hierarchical in nature. There
                            is
                            > > > > nothing wrong with telling the client how it can form URI's,
                            > > > > assuming that such a function doesn't change much over time.
                            > > > > Again, for cache reasons, I prefer methods of telling the
                            client
                            > > > > to use the template
                            > > > >
                            > > > > http://example.com/quotes/${exchange}/${symbol}
                            > > > >
                            > > > > rather than the template
                            > > > >
                            > > > > http://example.com/quotes?market=${exchange}
                            &symbol=${symbol}
                            > > > >
                            > > > > There is nothing stopping WSDL-like technology from defining
                            > > > > both of these mechanisms.
                            > > > >
                            > > > > ....Roy
                            > > > >
                            > > >
                            > > > Hey, now there's an idea. Maybe even official WSDL
                            technology...
                            > >
                            > > *groan* Ok, sure, *now* you support my "make WSDL more form-like"
                            > > suggestions. 8-)
                            > >
                            > > The new HTTP binding goes further in this direction, but still
                            falls
                            > > short largely because it bumps up against the *very* different
                            demands
                            > > of a forms language compared with an interface description
                            language.
                            > >
                            > > I'd personally prefer to start over with a forms language, which
                            is
                            > > why I created RDF Forms; http://www.markbaker.ca/2003/05/RDF-
                            Forms/ .
                            > > But it has a bit of legacy in its support of www-form-urlencoded
                            > > serializations for POST bodies and URIs largely because that's
                            what
                            > > server APIs easily support and it's what I used at work. But I'd
                            love
                            > > to get a more general generative naming language in there that
                            could
                            > > support hierarchy as Roy describes.
                            > >
                            > > Mark.
                            > > --
                            > > Mark Baker. Ottawa, Ontario, CANADA.
                            http://www.markbaker.ca
                          • thompsonbry
                            In the category of never post before coffee , forget my remarks about caching GET with a request entity. However, I am interested in the relevance of this
                            Message 13 of 23 , Jun 2, 2004
                            • 0 Attachment
                              In the category of "never post before coffee", forget my remarks
                              about caching GET with a request entity.

                              However, I am interested in the relevance of this discussion to
                              XForms and GET.

                              -bryan

                              --- In rest-discuss@yahoogroups.com, "thompsonbry" <thompsonbry@s...>
                              wrote:
                              > This sounds very relevant to how XForms could use GET.
                              >
                              > I am assuming that we want the stronger constraint of
                              > bookmarkability, right? Not just caching?
                              >
                              > So that we are not talking about GET with a request body (which
                              could
                              > perhaps be made cachable, e.g., using "Vary") but a means of
                              mapping
                              > an XML document (which could be just a property set for flat vs
                              > hierarchical addressing) into a URI.
                              >
                              > E.g., a "application/iriencoded-xml" MIME type.
                              >
                              > -bryan
                              >
                              > --- In rest-discuss@yahoogroups.com, "David Orchard" <orchard@p...>
                              > wrote:
                              > > I've been looking at how map an xml tree into the path and same
                              > depth
                              > > params into the forms, ala
                              > >
                              >
                              <Music><Artist><Name>ThieveryCorp</Name><Rating>5</Rating></Artist></M
                              > us
                              > > ic>
                              > >
                              > > gets mapped into something like GET /Music/Artist?
                              Name=ThieveryCorp
                              > and
                              > > GET /Music/Artist/Rating?Name=ThieveryCorp
                              > >
                              > > Mixed ns are a pain, but if you adopt the convention that the ns
                              > decls
                              > > are somehow in the algorithm, then it gets a little bit more
                              > managable.
                              > >
                              > > Cheers,
                              > > Dave
                              > >
                              > > > -----Original Message-----
                              > > > From: Mark Baker [mailto:distobj@a...]
                              > > > Sent: Tuesday, June 01, 2004 8:38 PM
                              > > > To: David Orchard
                              > > > Cc: rest-discuss@yahoogroups.com
                              > > > Subject: Re: [rest-discuss] Re-using information fields for
                              > queries in
                              > > > REST
                              > > >
                              > > >
                              > > > On Tue, Jun 01, 2004 at 05:47:54PM -0700, David Orchard wrote:
                              > > > > Gotcha on the use of hierarchy rather than flat where
                              > appropriate.
                              > > > >
                              > > > > > -----Original Message-----
                              > > > > > From: Roy T. Fielding [mailto:fielding@g...]
                              > > > >
                              > > > > <snip/>
                              > > > > > Anyway, we are talking about resource discovery over
                              arbitrary
                              > > > > > data categories, and hence non-hierarchical in nature.
                              There
                              > is
                              > > > > > nothing wrong with telling the client how it can form URI's,
                              > > > > > assuming that such a function doesn't change much over time.
                              > > > > > Again, for cache reasons, I prefer methods of telling the
                              > client
                              > > > > > to use the template
                              > > > > >
                              > > > > > http://example.com/quotes/${exchange}/${symbol}
                              > > > > >
                              > > > > > rather than the template
                              > > > > >
                              > > > > > http://example.com/quotes?market=${exchange}
                              > &symbol=${symbol}
                              > > > > >
                              > > > > > There is nothing stopping WSDL-like technology from defining
                              > > > > > both of these mechanisms.
                              > > > > >
                              > > > > > ....Roy
                              > > > > >
                              > > > >
                              > > > > Hey, now there's an idea. Maybe even official WSDL
                              > technology...
                              > > >
                              > > > *groan* Ok, sure, *now* you support my "make WSDL more form-
                              like"
                              > > > suggestions. 8-)
                              > > >
                              > > > The new HTTP binding goes further in this direction, but still
                              > falls
                              > > > short largely because it bumps up against the *very* different
                              > demands
                              > > > of a forms language compared with an interface description
                              > language.
                              > > >
                              > > > I'd personally prefer to start over with a forms language,
                              which
                              > is
                              > > > why I created RDF Forms; http://www.markbaker.ca/2003/05/RDF-
                              > Forms/ .
                              > > > But it has a bit of legacy in its support of www-form-urlencoded
                              > > > serializations for POST bodies and URIs largely because that's
                              > what
                              > > > server APIs easily support and it's what I used at work. But
                              I'd
                              > love
                              > > > to get a more general generative naming language in there that
                              > could
                              > > > support hierarchy as Roy describes.
                              > > >
                              > > > Mark.
                              > > > --
                              > > > Mark Baker. Ottawa, Ontario, CANADA.
                              > http://www.markbaker.ca
                            • David Orchard
                              I think one of the hardest parts of coming up with a uriencoded-xml format is dealing with those pesky QNames. I wrote a while ago about this
                              Message 14 of 23 , Jun 2, 2004
                              • 0 Attachment
                                I think one of the hardest parts of coming up with a "uriencoded-xml" format is dealing with those pesky QNames.  I wrote a while ago about this http://www.pacificspirit.com/blog/2004/04/29/binding_qnames_to_uris
                                 
                                I've almost gotten to the point of thinking that it's just simply to awful to binding lexical QNames or NS decls to URIs for binding potentially many qnames to URIs.  The approach of specifying that the ns decl is part of the "algorithm" allows for I think a pretty common case, the authority creating the resources can specify the ns name decls ahead of time.  In this case, the creator of the Author resources not surprisingly owns the Author namespace names.  A prefix is not required for the default namespace, and a prefix is required for using ns decls outside the default ns.  
                                 
                                There is a big downside in that the xml fragments are no-longer self-describing as they are missing their ns decls in-line.  If somebody changes the namespace name but not the ns prefix, things could get pretty hairy.  And distributed extensibility wouldn't be supported as a client that knew about a davens:extension that was unknown to the service wouldn't be able to send the extension they know about but wasn't in the algorithm.  I suppose it could be possible to say that extensions can be sent in ugly lexical form as that is the "hard but possible" case in the "make simple things simple and hard things possible" algorithm.
                                 
                                In retrospect, I'm becoming convinced that marrying XML sans namespace tree structures to the URI tree and query structure works fine, but marrying XML namespaced tree structures to URIs has been almost useless by the decision to make ns names absolute URIs.  In order to map some kind of xml to URIs, we have to adopt some kind of constraints, like "ns decls are implicit", to make it usable.  One thing I am curious about is whether people see much need for mapping mixed ns xml into URIs, or if most of the scenarios involved single ns..
                                 
                                Cheers,
                                Dave
                                -----Original Message-----
                                From: thompsonbry [mailto:thompsonbry@...]
                                Sent: Wednesday, June 02, 2004 4:51 AM
                                To: rest-discuss@yahoogroups.com
                                Subject: [rest-discuss] Re: Re-using information fields for queries in REST

                                This sounds very relevant to how XForms could use GET.

                                I am assuming that we want the stronger constraint of
                                bookmarkability, right?  Not just caching?

                                So that we are not talking about GET with a request body (which could
                                perhaps be made cachable, e.g., using "Vary") but a means of mapping
                                an XML document (which could be just a property set for flat vs
                                hierarchical addressing) into a URI.

                                E.g., a "application/iriencoded-xml" MIME type.

                                -bryan

                                --- In rest-discuss@yahoogroups.com, "David Orchard" <orchard@p...>
                                wrote:
                                > I've been looking at how map an xml tree into the path and same
                                depth
                                > params into the forms, ala
                                >
                                <Music><Artist><Name>ThieveryCorp</Name><Rating>5</Rating></Artist></M
                                us
                                > ic>
                                >
                                > gets mapped into something like GET /Music/Artist?Name=ThieveryCorp
                                and
                                > GET /Music/Artist/Rating?Name=ThieveryCorp
                                >
                                > Mixed ns are a pain, but if you adopt the convention that the ns
                                decls
                                > are somehow in the algorithm, then it gets a little bit more
                                managable.
                                >
                                > Cheers,
                                > Dave
                                >
                                > > -----Original Message-----
                                > > From: Mark Baker [mailto:distobj@a...]
                                > > Sent: Tuesday, June 01, 2004 8:38 PM
                                > > To: David Orchard
                                > > Cc: rest-discuss@yahoogroups.com
                                > > Subject: Re: [rest-discuss] Re-using information fields for
                                queries in
                                > > REST
                                > >
                                > >
                                > > On Tue, Jun 01, 2004 at 05:47:54PM -0700, David Orchard wrote:
                                > > > Gotcha on the use of hierarchy rather than flat where
                                appropriate.
                                > > >
                                > > > > -----Original Message-----
                                > > > > From: Roy T. Fielding [mailto:fielding@g...]
                                > > >
                                > > > <snip/>
                                > > > > Anyway, we are talking about resource discovery over arbitrary
                                > > > > data categories, and hence non-hierarchical in nature.  There
                                is
                                > > > > nothing wrong with telling the client how it can form URI's,
                                > > > > assuming that such a function doesn't change much over time.
                                > > > > Again, for cache reasons, I prefer methods of telling the
                                client
                                > > > > to use the template
                                > > > >
                                > > > >     http://example.com/quotes/${exchange}/${symbol}
                                > > > >
                                > > > > rather than the template
                                > > > >
                                > > > >     http://example.com/quotes?market=${exchange}
                                &symbol=${symbol}
                                > > > >
                                > > > > There is nothing stopping WSDL-like technology from defining
                                > > > > both of these mechanisms.
                                > > > >
                                > > > > ....Roy
                                > > > >
                                > > >
                                > > > Hey, now there's an idea.  Maybe even official WSDL
                                technology...
                                > >
                                > > *groan*  Ok, sure, *now* you support my "make WSDL more form-like"
                                > > suggestions. 8-)
                                > >
                                > > The new HTTP binding goes further in this direction, but still
                                falls
                                > > short largely because it bumps up against the *very* different
                                demands
                                > > of a forms language compared with an interface description
                                language.
                                > >
                                > > I'd personally prefer to start over with a forms language, which
                                is
                                > > why I created RDF Forms; http://www.markbaker.ca/2003/05/RDF-
                                Forms/ .
                                > > But it has a bit of legacy in its support of www-form-urlencoded
                                > > serializations for POST bodies and URIs largely because that's
                                what
                                > > server APIs easily support and it's what I used at work.  But I'd
                                love
                                > > to get a more general generative naming language in there that
                                could
                                > > support hierarchy as Roy describes.
                                > >
                                > > Mark.
                                > > --
                                > > Mark Baker.   Ottawa, Ontario, CANADA.       
                                http://www.markbaker.ca


                              • thompsonbry
                                Dave, I searched on this a bit, but I could not find the gospel according to the TAG. However, it is my rememberance that URIs no longer have practical length
                                Message 15 of 23 , Jun 3, 2004
                                • 0 Attachment
                                  Dave,

                                  I searched on this a bit, but I could not find the gospel according
                                  to the TAG. However, it is my rememberance that URIs no longer have
                                  practical length limits and that people should not design interfaces
                                  as if they did.

                                  So, why not just serialize the XML using the XML syntax in, e.g.,
                                  UTF-8, and then escape any characters that need to be escaped for
                                  the URI encoding?

                                  I mean, we can probably do better than this, e.g., with a dictionary
                                  of namespace URIs, element names and attribute names that would yield
                                  a more compact representation of the XML instance data (all of which
                                  reminds me of binary XML), but why bother? Is't it good enough to do
                                  this in the simplest manner possible so that we can move forward?

                                  -bryan

                                  --- In rest-discuss@yahoogroups.com, "David Orchard" <orchard@p...>
                                  wrote:
                                  > I think one of the hardest parts of coming up with a "uriencoded-
                                  xml" format is dealing with those pesky QNames. I wrote a while ago
                                  about this
                                  http://www.pacificspirit.com/blog/2004/04/29/binding_qnames_to_uris.
                                  >
                                  > I've almost gotten to the point of thinking that it's just simply
                                  to awful to binding lexical QNames or NS decls to URIs for binding
                                  potentially many qnames to URIs. The approach of specifying that the
                                  ns decl is part of the "algorithm" allows for I think a pretty common
                                  case, the authority creating the resources can specify the ns name
                                  decls ahead of time. In this case, the creator of the Author
                                  resources not surprisingly owns the Author namespace names. A prefix
                                  is not required for the default namespace, and a prefix is required
                                  for using ns decls outside the default ns.
                                  >
                                  > There is a big downside in that the xml fragments are no-longer
                                  self-describing as they are missing their ns decls in-line. If
                                  somebody changes the namespace name but not the ns prefix, things
                                  could get pretty hairy. And distributed extensibility wouldn't be
                                  supported as a client that knew about a davens:extension that was
                                  unknown to the service wouldn't be able to send the extension they
                                  know about but wasn't in the algorithm. I suppose it could be
                                  possible to say that extensions can be sent in ugly lexical form as
                                  that is the "hard but possible" case in the "make simple things
                                  simple and hard things possible" algorithm.
                                  >
                                  > In retrospect, I'm becoming convinced that marrying XML sans
                                  namespace tree structures to the URI tree and query structure works
                                  fine, but marrying XML namespaced tree structures to URIs has been
                                  almost useless by the decision to make ns names absolute URIs. In
                                  order to map some kind of xml to URIs, we have to adopt some kind of
                                  constraints, like "ns decls are implicit", to make it usable. One
                                  thing I am curious about is whether people see much need for mapping
                                  mixed ns xml into URIs, or if most of the scenarios involved single
                                  ns..
                                  >
                                  > Cheers,
                                  > Dave
                                  >
                                  > -----Original Message-----
                                  > From: thompsonbry [mailto:thompsonbry@s...]
                                  > Sent: Wednesday, June 02, 2004 4:51 AM
                                  > To: rest-discuss@yahoogroups.com
                                  > Subject: [rest-discuss] Re: Re-using information fields for queries
                                  in REST
                                  >
                                  >
                                  > This sounds very relevant to how XForms could use GET.
                                  >
                                  > I am assuming that we want the stronger constraint of
                                  > bookmarkability, right? Not just caching?
                                  >
                                  > So that we are not talking about GET with a request body (which
                                  could
                                  > perhaps be made cachable, e.g., using "Vary") but a means of
                                  mapping
                                  > an XML document (which could be just a property set for flat vs
                                  > hierarchical addressing) into a URI.
                                  >
                                  > E.g., a "application/iriencoded-xml" MIME type.
                                  >
                                  > -bryan
                                  >
                                  > --- In rest-discuss@yahoogroups.com, "David Orchard" <orchard@p...>
                                  > wrote:
                                  > > I've been looking at how map an xml tree into the path and same
                                  > depth
                                  > > params into the forms, ala
                                  > >
                                  >
                                  <Music><Artist><Name>ThieveryCorp</Name><Rating>5</Rating></Artist></M
                                  > us
                                  > > ic>
                                  > >
                                  > > gets mapped into something like GET /Music/Artist?
                                  Name=ThieveryCorp
                                  > and
                                  > > GET /Music/Artist/Rating?Name=ThieveryCorp
                                  > >
                                  > > Mixed ns are a pain, but if you adopt the convention that the ns
                                  > decls
                                  > > are somehow in the algorithm, then it gets a little bit more
                                  > managable.
                                  > >
                                  > > Cheers,
                                  > > Dave
                                  > >
                                  > > > -----Original Message-----
                                  > > > From: Mark Baker [mailto:distobj@a...]
                                  > > > Sent: Tuesday, June 01, 2004 8:38 PM
                                  > > > To: David Orchard
                                  > > > Cc: rest-discuss@yahoogroups.com
                                  > > > Subject: Re: [rest-discuss] Re-using information fields for
                                  > queries in
                                  > > > REST
                                  > > >
                                  > > >
                                  > > > On Tue, Jun 01, 2004 at 05:47:54PM -0700, David Orchard wrote:
                                  > > > > Gotcha on the use of hierarchy rather than flat where
                                  > appropriate.
                                  > > > >
                                  > > > > > -----Original Message-----
                                  > > > > > From: Roy T. Fielding [mailto:fielding@g...]
                                  > > > >
                                  > > > > <snip/>
                                  > > > > > Anyway, we are talking about resource discovery over
                                  arbitrary
                                  > > > > > data categories, and hence non-hierarchical in nature.
                                  There
                                  > is
                                  > > > > > nothing wrong with telling the client how it can form URI's,
                                  > > > > > assuming that such a function doesn't change much over time.
                                  > > > > > Again, for cache reasons, I prefer methods of telling the
                                  > client
                                  > > > > > to use the template
                                  > > > > >
                                  > > > > > http://example.com/quotes/${exchange}/${symbol}
                                  > > > > >
                                  > > > > > rather than the template
                                  > > > > >
                                  > > > > > http://example.com/quotes?market=${exchange}
                                  > &symbol=${symbol}
                                  > > > > >
                                  > > > > > There is nothing stopping WSDL-like technology from defining
                                  > > > > > both of these mechanisms.
                                  > > > > >
                                  > > > > > ....Roy
                                  > > > > >
                                  > > > >
                                  > > > > Hey, now there's an idea. Maybe even official WSDL
                                  > technology...
                                  > > >
                                  > > > *groan* Ok, sure, *now* you support my "make WSDL more form-
                                  like"
                                  > > > suggestions. 8-)
                                  > > >
                                  > > > The new HTTP binding goes further in this direction, but still
                                  > falls
                                  > > > short largely because it bumps up against the *very* different
                                  > demands
                                  > > > of a forms language compared with an interface description
                                  > language.
                                  > > >
                                  > > > I'd personally prefer to start over with a forms language,
                                  which
                                  > is
                                  > > > why I created RDF Forms; http://www.markbaker.ca/2003/05/RDF-
                                  > Forms/ .
                                  > > > But it has a bit of legacy in its support of www-form-urlencoded
                                  > > > serializations for POST bodies and URIs largely because that's
                                  > what
                                  > > > server APIs easily support and it's what I used at work. But
                                  I'd
                                  > love
                                  > > > to get a more general generative naming language in there that
                                  > could
                                  > > > support hierarchy as Roy describes.
                                  > > >
                                  > > > Mark.
                                  > > > --
                                  > > > Mark Baker. Ottawa, Ontario, CANADA.
                                  > http://www.markbaker.ca
                                  >
                                  >
                                  >
                                  > Yahoo! Groups Sponsor
                                  >
                                  > ADVERTISEMENT
                                  >
                                  <http://rd.yahoo.com/SIG=129ga231f/M=295196.4901138.6071305.3001176/D=
                                  groups/S=1705701014:HM/EXP=1086263534/A=2128215/R=0/SIG=10se96mf6/*htt
                                  p://companion.yahoo.com> click here
                                  > <http://us.adserver.yahoo.com/l?
                                  M=295196.4901138.6071305.3001176/D=groups/S=:HM/A=2128215/rand=2945531
                                  86>
                                  >
                                  >
                                  > _____
                                  >
                                  > Yahoo! Groups Links
                                  >
                                  >
                                  > * To visit your group on the web, go to:
                                  > http://groups.yahoo.com/group/rest-discuss/
                                  >
                                  >
                                  > * To unsubscribe from this group, send an email to:
                                  > rest-discuss-unsubscribe@yahoogroups.com <mailto:rest-discuss-
                                  unsubscribe@yahoogroups.com?subject=Unsubscribe>
                                  >
                                  >
                                  > * Your use of Yahoo! Groups is subject to the Yahoo! Terms of
                                  Service <http://docs.yahoo.com/info/terms/> .
                                • Neil Kandalgaonkar
                                  n.b. slightly reworded from a reply I accidentally posted to the author. ... There seems to be a lot of discussion about how the URIs in a REST system should
                                  Message 16 of 23 , Jun 11, 2004
                                  • 0 Attachment
                                    n.b. slightly reworded from a reply I accidentally posted to the
                                    author.

                                    --- In rest-discuss@yahoogroups.com, "David Orchard" <orchard@p...>
                                    wrote:

                                    > Why is discovery of a particular URI "better" than discovery
                                    > of the construction technique for a URI? This argues that HTML
                                    > FORM GETs are a bad way of creating URIs because they are
                                    > fabricated.

                                    There seems to be a lot of discussion about how the URIs in a REST
                                    system should look. Or how they map to server data structures.

                                    Maybe I'm behind the times here -- Roy seems to want a WSDL-like
                                    technology to allow you to compose URIs. But does the URI really
                                    matter?

                                    Paul Prescod argues[1] that the URIs in a REST system ought to be
                                    thought of as opaque. You would only discover them as links from other
                                    results obtained in the REST system.

                                    You could unite different servers with totally different
                                    URI-construction conventions this way -- just like the HTML web.

                                    Of course you might *want* the URI to make sense to a human, but that
                                    could be ad hoc and cosmetic.


                                    [1] See point 3 on <http://prescod.net/rest/mistakes/>: "My rule of
                                    thumb is that clients only construct URIs when they are building
                                    queries (and thus using query strings). Those queries return
                                    references to objects with opaque URIs."
                                  • S. Mike Dierken
                                    ... My opinion is that both are tools, with benefits and costs. Both are widely used - discovery via href= attributes and generative via FORMs. The discovery
                                    Message 17 of 23 , Jun 11, 2004
                                    • 0 Attachment
                                      >
                                      > > Why is discovery of a particular URI "better" than discovery
                                      > > of the construction technique for a URI? This argues that HTML
                                      > > FORM GETs are a bad way of creating URIs because they are
                                      > > fabricated.
                                      >
                                      > There seems to be a lot of discussion about how the URIs in a REST
                                      > system should look. Or how they map to server data structures.
                                      >
                                      > Maybe I'm behind the times here -- Roy seems to want a WSDL-like
                                      > technology to allow you to compose URIs. But does the URI really
                                      > matter?
                                      >
                                      > Paul Prescod argues[1] that the URIs in a REST system ought to be
                                      > thought of as opaque. You would only discover them as links from other
                                      > results obtained in the REST system.

                                      My opinion is that both are tools, with benefits and costs. Both are widely
                                      used - discovery via href= attributes and generative via FORMs. The
                                      discovery via href= style attributes is pretty simple and 'standard'. The
                                      construction of URI based on a service meta-description is more complex and
                                      not widely used outside of HTML - I'd love to see a more powerful version
                                      put forth & accepted by the community.
                                    • Neil Kandalgaonkar
                                      ... In HTML, aren t the vast majority of URIs just provided in links? Do you mean forms? Because, of course, that s a good standard for transforming client
                                      Message 18 of 23 , Jun 14, 2004
                                      • 0 Attachment
                                        --- "S. Mike Dierken" <mdierken@...> wrote:

                                        > The construction of URI based on a service meta-description is
                                        > more complex and
                                        > not widely used outside of HTML - I'd love to see a more powerful
                                        > version
                                        > put forth & accepted by the community.

                                        In HTML, aren't the vast majority of URIs just provided in links?

                                        Do you mean forms? Because, of course, that's a good standard for
                                        transforming client data into the query section of a URI.

                                        So I think the question is: do we need another standard for clients
                                        to transform user data into the *path* section? In a way customized
                                        to each REST application?

                                        My first guess is no, but I'd like to hear potential uses first. Why
                                        would you want to compose such a URI path? Why *wouldn't* you want to
                                        do the same thing with a URI query?



                                        =====
                                        --
                                        Neil Kandalgaonkar
                                        neil_j_k@...
                                      • S. Mike Dierken
                                        ... I d like a general mechanism for constructing a request - regardless of URI path, URI query terms, request headers, etc. I d settle for complete access to
                                        Message 19 of 23 , Jun 14, 2004
                                        • 0 Attachment
                                          > So I think the question is: do we need another standard for clients
                                          > to transform user data into the *path* section? In a way customized
                                          > to each REST application?
                                          >
                                          > My first guess is no, but I'd like to hear potential uses first. Why
                                          > would you want to compose such a URI path? Why *wouldn't* you want to
                                          > do the same thing with a URI query?

                                          I'd like a general mechanism for constructing a request - regardless of URI
                                          path, URI query terms, request headers, etc. I'd settle for complete access
                                          to the request method and the URI.
                                        • Mark Baker
                                          ... RDF Forms is intended to be such a mechanism ... or at least it will be once I finish everything in the todo list. As is, it just tries to do what HTML
                                          Message 20 of 23 , Jun 14, 2004
                                          • 0 Attachment
                                            On Mon, Jun 14, 2004 at 09:10:56PM -0700, S. Mike Dierken wrote:
                                            >
                                            > > So I think the question is: do we need another standard for clients
                                            > > to transform user data into the *path* section? In a way customized
                                            > > to each REST application?
                                            > >
                                            > > My first guess is no, but I'd like to hear potential uses first. Why
                                            > > would you want to compose such a URI path? Why *wouldn't* you want to
                                            > > do the same thing with a URI query?
                                            >
                                            > I'd like a general mechanism for constructing a request - regardless of URI
                                            > path, URI query terms, request headers, etc. I'd settle for complete access
                                            > to the request method and the URI.

                                            RDF Forms is intended to be such a mechanism ... or at least it will be
                                            once I finish everything in the todo list. As is, it just tries to do
                                            what HTML forms can do.

                                            http://www.markbaker.ca/2003/05/RDF-Forms/

                                            Mark.
                                            --
                                            Mark Baker. Ottawa, Ontario, CANADA. http://www.markbaker.ca
                                          • Jeff Bone
                                            ... Yes - explicit ones. We re talking about having the servers specify generation rules for whole classes of valid URI, not merely passing out explicit lists
                                            Message 21 of 23 , Jun 15, 2004
                                            • 0 Attachment
                                              On Jun 14, 2004, at 5:55 PM, Neil Kandalgaonkar wrote:

                                              > In HTML, aren't the vast majority of URIs just provided in links?

                                              Yes - explicit ones. We're talking about having the servers specify
                                              generation rules for whole classes of valid URI, not merely passing out
                                              explicit lists of them.

                                              > Do you mean forms? Because, of course, that's a good standard for
                                              > transforming client data into the query section of a URI.
                                              >
                                              > So I think the question is: do we need another standard for clients
                                              > to transform user data into the *path* section? In a way customized
                                              > to each REST application?

                                              Whether it's in the query or the path is somewhat orthogonal to the
                                              desire to express URI generatively. The preference for having such a
                                              mechanism that works both with path parts and query parts is driven
                                              mostly by caching concerns, otherwise somewhat by a resource modeling
                                              philosophy that says conceptual hierarchy in the model should be
                                              expressed as such in URI.

                                              Cf., w/ caveat that this is purely my own (and early, not recently
                                              revisited) thoughts on this:

                                              http://rest.blueoxen.net/cgi-bin/wiki.pl?GenerativeNaming

                                              and

                                              http://rest.blueoxen.net/cgi-bin/wiki.pl?NamingIsntNavigating

                                              Also check out Mark Nottingham's related thoughts on a WSDL approach to
                                              this:

                                              http://www.mnot.net/blog/2004/04/16/generative

                                              and

                                              http://www.mnot.net/blog/2003/12/07/webdesc

                                              jb
                                            • David Orchard
                                              here, here. As you can guess, I ve been working on this, but it s damned hard. ... From: S. Mike Dierken [mailto:mdierken@hotmail.com] Sent: Monday, June 14,
                                              Message 22 of 23 , Jun 17, 2004
                                              • 0 Attachment
                                                here, here.  As you can guess, I've been working on this, but it's damned hard. 
                                                -----Original Message-----
                                                From: S. Mike Dierken [mailto:mdierken@...]
                                                Sent: Monday, June 14, 2004 9:11 PM
                                                To: neil_j_k@...; rest-discuss@yahoogroups.com
                                                Subject: Re: [rest-discuss] Client-composed URI paths


                                                > So I think the question is: do we need another standard for clients
                                                > to transform user data into the *path* section? In a way customized
                                                > to each REST application?
                                                >
                                                > My first guess is no, but I'd like to hear potential uses first. Why
                                                > would you want to compose such a URI path? Why *wouldn't* you want to
                                                > do the same thing with a URI query?

                                                I'd like a general mechanism for constructing a request - regardless of URI
                                                path, URI query terms, request headers, etc. I'd settle for complete access
                                                to the request method and the URI.

                                              • David Orchard
                                                We ve been looking at this in the WSD WG. The WSDL 2.0 HTTP binding has a mechanism for specifying how a URI space is populated based upon schema and instance
                                                Message 23 of 23 , Jun 22, 2004
                                                • 0 Attachment
                                                  We've been looking at this in the WSD WG.  The WSDL 2.0 HTTP binding has a mechanism for specifying how a URI space is populated based upon schema and instance data.  I've tried my hand at creating an example of the Artist showing how the HTTP binding would be used at
                                                   
                                                   
                                                  I kind of think it sucks, it's too complicated and it doesn't seem to make the simple things simple, as I describe in the message.
                                                   
                                                  Also, there's some use of HTTP headers in REST, which we haven't formally done in the WSD until now.  We've been working on a proposal for how to specify out-of-band, or Application Data, that is intended to be serialized as HTTP or SOAP headers.  Myself and Glenn have responsibility for this in WSD, and we're almost there, but it's not quite ready. 
                                                   
                                                  Cheers,
                                                  Dave
                                                  -----Original Message-----
                                                  From: Jeff Bone [mailto:jbone@...]
                                                  Sent: Tuesday, June 15, 2004 12:23 AM
                                                  To: neil_j_k@...
                                                  Cc: rest-discuss@yahoogroups.com
                                                  Subject: Re: [rest-discuss] Client-composed URI paths


                                                  On Jun 14, 2004, at 5:55 PM, Neil Kandalgaonkar wrote:

                                                  > In HTML, aren't the vast majority of URIs just provided in links?

                                                  Yes - explicit ones.  We're talking about having the servers specify
                                                  generation rules for whole classes of valid URI, not merely passing out
                                                  explicit lists of them.

                                                  > Do you mean forms? Because, of course, that's a good standard for
                                                  > transforming client data into the query section of a URI.
                                                  >
                                                  > So I think the question is: do we need another standard for clients
                                                  > to transform user data into the *path* section? In a way customized
                                                  > to each REST application?

                                                  Whether it's in the query or the path is somewhat orthogonal to the
                                                  desire to express URI generatively.  The preference for having such a
                                                  mechanism that works both with path parts and query parts is driven
                                                  mostly by caching concerns, otherwise somewhat by a resource modeling
                                                  philosophy that says conceptual hierarchy in the model should be
                                                  expressed as such in URI.

                                                  Cf., w/ caveat that this is purely my own (and early, not recently
                                                  revisited) thoughts on this:

                                                        http://rest.blueoxen.net/cgi-bin/wiki.pl?GenerativeNaming

                                                  and

                                                        http://rest.blueoxen.net/cgi-bin/wiki.pl?NamingIsntNavigating

                                                  Also check out Mark Nottingham's related thoughts on a WSDL approach to
                                                  this:

                                                        http://www.mnot.net/blog/2004/04/16/generative

                                                  and

                                                        http://www.mnot.net/blog/2003/12/07/webdesc

                                                  jb




                                                Your message has been successfully submitted and would be delivered to recipients shortly.