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

Re: [rest-discuss] Re-using information fields for queries in REST

Expand Messages
  • 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 1 of 23 , Jun 1 12:58 PM
      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 2 of 23 , Jun 1 2:16 PM
        > -----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 3 of 23 , Jun 1 4:54 PM
          "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 4 of 23 , Jun 1 4:57 PM
            > 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 5 of 23 , Jun 1 5:47 PM
              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 6 of 23 , Jun 1 6:10 PM
                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 7 of 23 , Jun 1 8:37 PM
                  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 8 of 23 , Jun 1 9:41 PM
                    > 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 9 of 23 , Jun 1 9:53 PM
                      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 10 of 23 , Jun 2 4:51 AM
                        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 11 of 23 , Jun 2 5:20 AM
                          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 12 of 23 , Jun 2 9:28 AM
                            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 13 of 23 , Jun 3 7:42 AM
                              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 14 of 23 , Jun 11 1:47 PM
                                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 15 of 23 , Jun 11 10:22 PM
                                  >
                                  > > 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 16 of 23 , Jun 14 3:55 PM
                                    --- "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 17 of 23 , Jun 14 9:10 PM
                                      > 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 18 of 23 , Jun 14 9:46 PM
                                        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 19 of 23 , Jun 15 12:22 AM
                                          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 20 of 23 , Jun 17 3:06 PM
                                            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 21 of 23 , Jun 22 11:02 AM
                                              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.