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

Re: [rest-discuss] Identifiers: higher precedence than other fields?

Expand Messages
  • S. Mike Dierken
    ... describing ... server. ... consequently ... Oh. I guess I read it too quickly. ... as you ... determine ... You ll still have to generate the URI on the
    Message 1 of 18 , Jun 10, 2004
    • 0 Attachment
      > What I was tring to say, in my clumsy way, is that the approach I was
      describing
      > uses completely opaque paths that are always generated by the origin
      server.
      > There is no requirement for an User Agent to calculate the paths and
      consequently
      > the origin server can use any naming convention it wants to.
      Oh. I guess I read it too quickly.


      > As far as using external sources for generating references to resources,
      as you
      > describe above, the way I would do that is to query the system to
      determine
      > whether such an artist exists. So for example, the phone book lists a
      > "Lisa B Simpson" which could be used like this.
      >
      > GET /artist?name=Lisa%20B%20Simpson
      You'll still have to generate the URI on the client - why not just use
      "/artist/Lisa%20B%20Simpson" directly?
      Sure, the HTML FORM element only provides a way to construct query terms in
      a URI, but several people would like to go beyond that. Really wish we had a
      standardized syntax & sample libraries...

      >
      > The http path, /artist, suggests that only one artist should be returned,
      Not sure if that's a safe assumption. I suppose it's a reasonable guess -
      but I would easily implement something of similar naming that would return a
      list.
    • Donald Strong
      Hi Mike, ... Because /artist/Lisa%20B%20Simpson does not exist. It is an unvalidated URI manufactured by an external User Agent from an entry in a phone
      Message 2 of 18 , Jun 10, 2004
      • 0 Attachment
        Hi Mike,

        > > As far as using external sources for generating references to resources,
        > as you
        > > describe above, the way I would do that is to query the system to
        > determine
        > > whether such an artist exists. So for example, the phone book lists a
        > > "Lisa B Simpson" which could be used like this.
        > >
        > > GET /artist?name=Lisa%20B%20Simpson
        > You'll still have to generate the URI on the client - why not just use
        > "/artist/Lisa%20B%20Simpson" directly?

        Because "/artist/Lisa%20B%20Simpson" does not exist. It is an unvalidated
        URI manufactured by an external User Agent from an entry in a phone book.
        The URI on the Origin Server is "/artist/LisaSimpson".

        The /artist resource provides a mechanism for converting aliases into
        existing URI on the origin server. It could have been named
        /find-artist (but this URI is not restful because it is a
        verb or service, I think).

        > Sure, the HTML FORM element only provides a way to construct
        > query terms in
        > a URI, but several people would like to go beyond that. Really
        > wish we had a
        > standardized syntax & sample libraries...

        It depends upon which way you want to go. A User Agent is expected to
        treat a Path component (before the ?) as opaque but it is expected to
        understand and append query parameters to a search URI. I have
        been trying to locate where I read this, without success. It may have
        been in the HTML spec so perhaps this statement only applies to HTML
        but I thought it was in something more general than that.

        > > The http path, /artist, suggests that only one artist should be
        > returned,
        > Not sure if that's a safe assumption. I suppose it's a reasonable guess -
        > but I would easily implement something of similar naming that
        > would return a list.

        Looking back at my original post it is completely wrong. B^(
        I used /artist?name=Lisa%20Simpson and /artist?eye-color=Blue to
        return an <artistlist> so I cannot then use the same URI to return
        an individual artist. Perhaps /find-artist would be more appropriate.

        Regards
        Donald.
      • Walden Mathews
        Donald, ... I doubt the architectural impact of a name choice is really that significant. ... If /artist is understood to identify a set of artists, and
        Message 3 of 18 , Jun 11, 2004
        • 0 Attachment
          Donald,

          | The /artist resource provides a mechanism for converting aliases into
          | existing URI on the origin server. It could have been named
          | /find-artist (but this URI is not restful because it is a
          | verb or service, I think).

          I doubt the architectural impact of a name choice is
          really that significant.

          | Looking back at my original post it is completely wrong. B^(
          | I used /artist?name=Lisa%20Simpson and /artist?eye-color=Blue to
          | return an <artistlist> so I cannot then use the same URI to return
          | an individual artist. Perhaps /find-artist would be more appropriate.

          If /artist is understood to identify a set of artists, and /artist?<query
          params>
          is then understood to be a set of artists where the set contents is
          determined via "set comprehension" (as opposed to set enumeration),
          then the result of dereferencing these URIs is still a set, which could

          a) be empty

          b) contain a "singleton", or

          c) contain two or more artists

          As I suggested before, rather abstractly (and then Roy made quite
          concrete), in the case of b) above, the server might just like to
          redirect the client to the URI for that individual. That's a nice
          idiom for "you found exactly one".

          Walden
        • S. Mike Dierken
          ... Huh? The original suggestion of /artist?name=Lisa%20B%20Simpson is an unvalidated URI manufactured by an external user-agent also. The ? doesn t make it
          Message 4 of 18 , Jun 11, 2004
          • 0 Attachment
            > > > GET /artist?name=Lisa%20B%20Simpson
            > > You'll still have to generate the URI on the client - why not just use
            > > "/artist/Lisa%20B%20Simpson" directly?
            >
            > Because "/artist/Lisa%20B%20Simpson" does not exist. It is an unvalidated
            > URI manufactured by an external User Agent from an entry in a phone book.
            > The URI on the Origin Server is "/artist/LisaSimpson".

            Huh? The original suggestion of /artist?name=Lisa%20B%20Simpson is an
            unvalidated URI manufactured by an external user-agent also. The "?" doesn't
            make it special.
          • Donald Strong
            Hi Mike, Please note that these comments apply to the following message. http://groups.yahoo.com/group/rest-discuss/message/4441 I also realise from other
            Message 5 of 18 , Jun 15, 2004
            • 0 Attachment
              Hi Mike,

              Please note that these comments apply to the following message.
              http://groups.yahoo.com/group/rest-discuss/message/4441
              I also realise from other postings that this proposal does
              not apply to your particular problem. Possibly not David's
              either. Not sure who might find it useful. B^)

              > > > > GET /artist?name=Lisa%20B%20Simpson
              > > > You'll still have to generate the URI on the client - why not just use
              > > > "/artist/Lisa%20B%20Simpson" directly?
              > >
              > > Because "/artist/Lisa%20B%20Simpson" does not exist. It is an
              > unvalidated
              > > URI manufactured by an external User Agent from an entry in a
              > phone book.
              > > The URI on the Origin Server is "/artist/LisaSimpson".
              >
              > Huh? The original suggestion of /artist?name=Lisa%20B%20Simpson is an
              > unvalidated URI manufactured by an external user-agent also. The
              > "?" doesn't make it special.

              Well IMHO it does. At least as far as the design I am proposing.
              The question mark makes it a query. The query is directed to a URI
              that expects name/value pairs to be appended to it's URI by the
              User Agent. This is very HTML-forms-ish.

              This is a guess.

              GET /artist/Lisa%20B%20Simpson

              A wrong guess at that. It should return a 400 error code.

              This is a query.

              GET /find-artist?name=Lisa%20B%20Simpson

              It may return a redirect to the following URI which does exist,
              otherwise it will return a 400 error.

              /artist/LisaSimpson

              It is different from the following query that returns a,
              possibly empty, list of references to artists.

              GET /artist?name=Lisa%20B%20Simpson

              I think that the important part is that the client expects
              different results from different URIs.
              /find-artist?... returns a redirect to one artist or an error code
              while /artist?... returns a possibly empty list of artists matching
              the query. The former is used for resolving generated URIs, the
              latter is used for filtering the available artists.

              Regards
              Donald.
            • S. Mike Dierken
              ... Although it s a common approach on servers to route requests to a request handler based on the path portion only, the definition of URI encompasses all the
              Message 6 of 18 , Jun 15, 2004
              • 0 Attachment
                > > Huh? The original suggestion of /artist?name=Lisa%20B%20Simpson is an
                > > unvalidated URI manufactured by an external user-agent also. The
                > > "?" doesn't make it special.
                >
                > Well IMHO it does. At least as far as the design I am proposing.
                > The question mark makes it a query. The query is directed to a URI
                > that expects name/value pairs to be appended to it's URI by the
                > User Agent. This is very HTML-forms-ish.

                Although it's a common approach on servers to route requests to a request
                handler based on the path portion only, the definition of URI encompasses
                all the text, not just the stuff before the "?".
                I wouldn't suggest changing your approach at all, but just wanted to make
                sure you understood the HTTP spec.

                > The question mark makes it a query.
                Actually, the GET request method makes it a query from the client's point of
                view.

                A client could PUT, POST or DELETE to /artist?name=Lisa%20Simpson just as
                easily as to /artist/LisaSimpson with no observable difference because the
                URI should be treated as being opaque. But I'm probably beating a dead horse
                & I'll shut up now.
              • Walden Mathews
                ... of ... Different meanings for the word query . Donald is referring to what is more formally known as set comprehension*, a very loosely coupled way of
                Message 7 of 18 , Jun 16, 2004
                • 0 Attachment
                  | > The question mark makes it a query.
                  | Actually, the GET request method makes it a query from the client's point
                  of
                  | view.
                  |


                  Different meanings for the word 'query'. Donald is referring to what is
                  more formally known as set comprehension*, a very loosely coupled way
                  of specifying a set of web resources without knowledge of the implementer's
                  notions of hierarchy or other organization; just a partial knowledge of
                  properties gets things rolling.

                  (I think that's what Donad is referring to... :-)

                  * from Zermelo Fränkel set theory
                  [http://computing-dictionary.thefreedictionary.com/Zermelo%20set%20theory%5d

                  Walden
                • David Orchard
                  I laughed, I cried, when I got told to check out XPointer as to my regrest I was on the XPointer WG. I still haven t recovered from the agony and scars of
                  Message 8 of 18 , Jun 17, 2004
                  • 0 Attachment
                    I laughed, I cried, when I got told to check out XPointer as to my regrest I was on the XPointer WG.  I still haven't recovered from the agony and scars of that schmozzle.  That we didn't get an official frag id syntax for XML because we got railroaded into using Ranges still fills me with rage.  However, attempting to move on...
                     
                    You might be right in that I'm doing darned object thinking first rather than interface, but I'm trying...
                     
                    My problem is actually fairly simple in the abstract: I want to figure out the 80/20 point for unifying XML and the Web, hopefully hitting the 'make simple things simple and hard things possible' and then provide an effective and useful description format.
                     
                    From an architecture perspective, I see that we have 2 hierachical data structures (URI, infoset), 2+ identifier mechanisms (URI, ID, name), etc.  I roughly think that the Web and XML architecture are orthogonal. 
                     
                    Now, what can we do to make integration of URIs and XML and XML Schema easier?  What kind of constraints can we adopt that makes it possible to easily create XML web applications?
                    Ideas: default is no namespace name, xml element names are URI path components, identifier is in the URI path, xml identifier is the "name" attribute, URI query is never used for identifiers only queries, retrievals always return the lowest element in the hierarchy (artist or artist/bio instead of ArtistList/Artist..) etc.
                     
                    I'm not sure that the current WSDL 2.0 HTTP binding meets this point, and I'm trying to help fix that.  And if WSDL 2.0 isn't the right way to describe Web/XML components, then maybe some other format should be looked at in the w3c (or elsewhere).
                     
                    Cheers,
                    Dave
                    -----Original Message-----
                    From: Neil Kandalgaonkar [mailto:neil_j_k@...]
                    Sent: Friday, June 04, 2004 10:22 AM
                    To: rest-discuss@yahoogroups.com
                    Subject: Re: [rest-discuss] Identifiers: higher precedence than other fields?


                    --- David Orchard <orchard@...> wrote:
                    > It seems that any XML identifier is problematic to algorithmically
                    > map to a URI.

                    Yes. As you've noticed, this is impossible with just simple
                    directory-style slashes.

                    But can I suggest that you step back and ask what problem you're
                    trying to solve?

                    If your problem is "I have settled on XML, the documents will be
                    entirely freeform, and I want a uniform way of identifying any random
                    node so I can stuff them into URIs" then I guess you want XPath or
                    XPointer. Check them out. The expressions are very complex though.

                    However, if that *isn't* your problem, then perhaps you should think
                    about the URI interface first.  It seems to me that you really just
                    want:

                    http://host/artist/Thievery%20Corporation
                    http://host/artist/Thievery%20Corporation/bio
                    http://host/artist/Thievery%20Corporation/genre
                    http://host/artist/Thievery%20Corporation/website

                    You may protest that you have to write different get/set methods for
                    each one of those URIs! And what if your underlying data structure
                    changes?

                    However, some would say this is the beauty of REST. It forces you to
                    think about the consumers of your interfaces. Hiding the details is
                    good. This means you can change your underlying data structure at
                    will.


                    =====
                    --
                    Neil Kandalgaonkar
                    neil_j_k@...

                  • Neil Kandalgaonkar
                    ... Yeah... I know some XPath but only threw in XPointer because I d heard about it. I only realized afterwards you had written some XML-related standards. So
                    Message 9 of 18 , Jun 17, 2004
                    • 0 Attachment
                      --- David Orchard <dorchard@...> wrote:
                      > I laughed, I cried, when I got told to check out XPointer as to my
                      > regrest I was on the XPointer WG. I still haven't recovered from
                      > the
                      > agony and scars of that schmozzle.

                      Yeah... I know some XPath but only threw in XPointer because I'd
                      heard about it.

                      I only realized afterwards you had written some XML-related
                      standards. So the context of your question was more like "I know all
                      about XPath -- I'm looking for a simpler way" which I didn't get.
                      Sorry about that.



                      =====
                      --
                      Neil Kandalgaonkar
                      neil_j_k@...
                    • S. Mike Dierken
                      ... Ouch. ... I wasn t following that bit of standards work - does this imply no documented standard for using the stuff after the # character in URIs to
                      Message 10 of 18 , Jun 20, 2004
                      • 0 Attachment
                        > I laughed, I cried, when I got told to check out XPointer as to my regrest I was on the XPointer WG. 
                        Ouch.
                         
                        > That we didn't get an official frag id syntax for XML because we got railroaded into using Ranges still fills me with rage.
                        I wasn't following that bit of standards work - does this imply no documented standard for using the stuff after the '#' character in URIs to locate data inside the returned XML representation? Or were you shooting for sending the stuff after the '#' character up to the server?
                         
                        > Ideas: default is no namespace name, xml element names are URI path components, identifier is in the URI path,
                        > xml identifier is the "name" attribute, URI query is never used for identifiers only queries,
                        > retrievals always return the lowest element in the hierarchy (artist or artist/bio instead of ArtistList/Artist..) etc.
                        Some of this sounds familiar... I did a project (wound up on xml.apache.org, except it's derelict and abandoned) that used URIs to address into an XML document resident on the server. The 'document' was in fact a 'virtual document' and not just a single text file.
                         
                        Couple questions
                        > default is no namespace name,
                        No arguments here.
                         
                        > xml element names are URI path components,
                        Does this mean to put tag names in the path segments of a URI?
                        Is this intended to have similar meaning as XPath selection?
                        This implies that the request is to retrieve a resource that happens to be contained wholly within an XML document (or a synthesized, larger 'virtual' document), rather than retrieve a stored XML document identified by the URI. (I realize that from the client's perspective there is no way to tell these two apart, but I'm trying to figure out the intent through talking about expected implementation)
                        Let's see a concrete example. Pick a well known schema (something with at least three levels of element nesting - perhaps one of the numerous RSS formats or Atom - ignoring namespaces) and craft what some 'best practices' URI would look like.
                         
                        > identifier is in the URI path,
                        > xml identifier is the "name" attribute,
                        Are these two a suggested alternative to putting xml element names in the path segments mentioned previously?
                        This particular approach is the same as what I used in the Xang project (up on xml.apache.org - only look at the source if you are morbidly curious about servlet technologies from five years ago...). Very convenient and doesn't make the clients overly aware that the storage is in XML format or supports the XML data model. For
                         
                         
                        > URI query is never used for identifiers only queries,
                        There's a fine line between identifier and query. Again - I'm curious as to what the problem you are trying to solve is. Are you trying to come up with a reasonable 80/20 solution for addresing into XML data models (or infosets or what have you)? Or are you trying to come up with an approach for accessing any resource that supports returning XML representations?
                         
                        > retrievals always return the lowest element in the hierarchy (artist or artist/bio instead of ArtistList/Artist..) etc.
                        Not sure what this means - need to see an example.
                         
                         
                        ----- Original Message -----
                        Sent: Thursday, June 17, 2004 3:06 PM
                        Subject: RE: [rest-discuss] Identifiers: higher precedence than other fields?

                        I laughed, I cried, when I got told to check out XPointer as to my regrest I was on the XPointer WG.  I still haven't recovered from the agony and scars of that schmozzle.  That we didn't get an official frag id syntax for XML because we got railroaded into using Ranges still fills me with rage.  However, attempting to move on...
                         
                        You might be right in that I'm doing darned object thinking first rather than interface, but I'm trying...
                         
                        My problem is actually fairly simple in the abstract: I want to figure out the 80/20 point for unifying XML and the Web, hopefully hitting the 'make simple things simple and hard things possible' and then provide an effective and useful description format.
                         
                        From an architecture perspective, I see that we have 2 hierachical data structures (URI, infoset), 2+ identifier mechanisms (URI, ID, name), etc.  I roughly think that the Web and XML architecture are orthogonal. 
                         
                        Now, what can we do to make integration of URIs and XML and XML Schema easier?  What kind of constraints can we adopt that makes it possible to easily create XML web applications?
                        Ideas: default is no namespace name, xml element names are URI path components, identifier is in the URI path, xml identifier is the "name" attribute, URI query is never used for identifiers only queries, retrievals always return the lowest element in the hierarchy (artist or artist/bio instead of ArtistList/Artist..) etc.
                         
                        I'm not sure that the current WSDL 2.0 HTTP binding meets this point, and I'm trying to help fix that.  And if WSDL 2.0 isn't the right way to describe Web/XML components, then maybe some other format should be looked at in the w3c (or elsewhere).
                         
                        Cheers,
                        Dave
                        -----Original Message-----
                        From: Neil Kandalgaonkar [mailto:neil_j_k@...]
                        Sent: Friday, June 04, 2004 10:22 AM
                        To: rest-discuss@yahoogroups.com
                        Subject: Re: [rest-discuss] Identifiers: higher precedence than other fields?


                        --- David Orchard <orchard@...> wrote:
                        > It seems that any XML identifier is problematic to algorithmically
                        > map to a URI.

                        Yes. As you've noticed, this is impossible with just simple
                        directory-style slashes.

                        But can I suggest that you step back and ask what problem you're
                        trying to solve?

                        If your problem is "I have settled on XML, the documents will be
                        entirely freeform, and I want a uniform way of identifying any random
                        node so I can stuff them into URIs" then I guess you want XPath or
                        XPointer. Check them out. The expressions are very complex though.

                        However, if that *isn't* your problem, then perhaps you should think
                        about the URI interface first.  It seems to me that you really just
                        want:

                        http://host/artist/Thievery%20Corporation
                        http://host/artist/Thievery%20Corporation/bio
                        http://host/artist/Thievery%20Corporation/genre
                        http://host/artist/Thievery%20Corporation/website

                        You may protest that you have to write different get/set methods for
                        each one of those URIs! And what if your underlying data structure
                        changes?

                        However, some would say this is the beauty of REST. It forces you to
                        think about the consumers of your interfaces. Hiding the details is
                        good. This means you can change your underlying data structure at
                        will.


                        =====
                        --
                        Neil Kandalgaonkar
                        neil_j_k@...


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