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

The role of queries in REST?

Expand Messages
  • Roger L. Costello
    Hi Folks, My question is with regards to the role of a Web site in supporting queries. Let me give an example to demonstrate what I mean. Suppose that a Web
    Message 1 of 20 , May 6, 2005
    • 0 Attachment
      Hi Folks,
       
      My question is with regards to the role of a Web site in supporting queries.  Let me give an example to demonstrate what I mean.
       
      Suppose that a Web site implements this "hierarchical model of resources" for a bombing mission:
       
      Mission
          Plan1
               ...
          Plan2
              Aircraft
                  AA36
                      ...
                  BB06
                      Payload
                          Bomb1
                              ...
                          Bomb2
                              Fuze5
       
      By implementing this hierarchy the Web site gives users the ability to get any resource by simply composing a URL, where "/" is used to express a parent-child relationship in the resource hierarchy.  For example, to obtain the AA36 aircraft resource in Plan2 the user issues this URL:
       
       
      This is, of course, standard REST.
       
      Now consider this problem: how would the Web site support the many kinds of queries that a user might want to make, e.g.,
       
          "Tell me all the Aircraft that carry Bomb1"
       
      The first approach that comes to mind is for the Web site to make available a "form" that the user can retrieve, fill in, and return.  The Web site parses the form to extract the query, processes it, and returns the results to the user.
       
      However, there is a problem with this approach.  There are virtually infinitely many different kinds of queries that  users may want to make.  How can a Web site possibly provide a form for every conceivable kind of query?  It would be impossible to anticipate every kind of query that users might want to make.
       
      More importantly, I believe that focusing on "forms" is missing the point of REST.
       
      Let me now restate my original question:
       
          What is the role of queries in a REST-based system?  How can a Web site give
          users the ability to retrieve the kinds of custom data that they desire?  
          How are queries done in a RESTful manner?
       
      Below are some thoughts that I have on this issue. 
       
      I believe that the REST model can be simply summed up as:
       
           "A Web site is composed of resources.  A Web site should provide a URL to  
            each resource and enable the exchange, updating and deleting of resources". 
       
      Thus, with REST it is always an exchange of resources and nothing else.
       
      So when we start talking about a user filling in a form we are either talking about a "form resource" or we are breaking away from the REST model.  If we are talking about a "form resource" then how would it fit into the above mission resource hierarchy?
       
      I believe that it is not appropriate in REST to talk about forms.  Instead, we should talk about resources. 
       
      I believe that with the REST model the idea of issuing queries doesn't make sense.  With REST we exchange resources, not queries.
       
      That said, I understand the desire to enable a user to query to a Web site for information such as "what aircraft carry Bomb1?". 
       
      One solution is: this is a user processing issue, not a Web site resource issue, so it is outside the scope of REST.  In other words, if a user wants to know what aircraft carry Bomb1 then it is up to the user to retrieve each aircraft resource and do processing on each aircraft resource to determine if it carries Bomb1.
       
      That's not a particularly satisfying solution.  Perhaps there a way to rephrase the question so that it involves an exchange of resources, rather than a query exchange?   
       
      I would appreciate hearing your thoughts on this issue.  /Roger
    • Jan Algermissen
      Hi Roger, I think there are two kinds of querying: (1) retrieving subsets of large collections by parameterization (see Mark s indexable resource type). A
      Message 2 of 20 , May 6, 2005
      • 0 Attachment
        Hi Roger,

        I think there are two kinds of querying:

        (1) retrieving subsets of large collections by parameterization (see Mark's
        'indexable' resource type). A Web search is an example of this,
        where the
        intention is to specify a subset of the entire (indexed) web.

        (2) specifying previously unknown resource collections by arbitrarily
        complex
        queries based on properties of the resources ('all cars that are yellow
        and built after 1987'). Relational queries (SQL) are an example of this.
        The huge difference to (1) is that there are no parameterization options
        provided by the server but that the client uses knowledge about some
        domain
        model to construct the query.

        I think (1) perfectly suits REST's application model but (2) doesn't. I
        suppose the
        reason is that in case (2) the client makes assumptions about the
        resources that
        are beyond the information it retrives from the server. This is a form
        of unRESTful
        coupling (of the client to the specific domain model). If the domain
        model changes,
        the queries break (IMHO the reason why the relational model and OO-model
        are such
        obstacles in Data Integration/EAI scenarios).

        Jan



        Roger L. Costello wrote:

        > Hi Folks,
        >
        > My question is with regards to the role of a Web site in supporting
        > queries. Let me give an example to demonstrate what I mean.
        >
        > Suppose that a Web site implements this "hierarchical model of
        > resources" for a bombing mission:
        >
        > Mission
        > Plan1
        > ...
        > Plan2
        > Aircraft
        > AA36
        > ...
        > BB06
        > Payload
        > Bomb1
        > ...
        > Bomb2
        > Fuze5
        >
        > By implementing this hierarchy the Web site gives users the ability to
        > get any resource by simply composing a URL, where "/" is used to
        > express a parent-child relationship in the resource hierarchy. For
        > example, to obtain the AA36 aircraft resource in Plan2 the user issues
        > this URL:
        >
        > http://[hostname]/Mission/Plan2/Aircraft/AA36
        > <http://%5Bhostname%5D/Mission/Plan2/Aircraft/AA36>
        >
        > This is, of course, standard REST.
        >
        > Now consider this problem: how would the Web site support the many
        > kinds of queries that a user might want to make, e.g.,
        >
        > "Tell me all the Aircraft that carry Bomb1"
        >
        > The first approach that comes to mind is for the Web site to make
        > available a "form" that the user can retrieve, fill in, and return.
        > The Web site parses the form to extract the query, processes it, and
        > returns the results to the user.
        >
        > However, there is a problem with this approach. There are virtually
        > infinitely many different kinds of queries that users may want to
        > make. How can a Web site possibly provide a form for every
        > conceivable kind of query? It would be impossible to anticipate
        > every kind of query that users might want to make.
        >
        > More importantly, I believe that focusing on "forms" is missing the
        > point of REST.
        >
        > Let me now restate my original question:
        >
        > What is the role of queries in a REST-based system? How can a Web
        > site give
        > users the ability to retrieve the kinds of custom data that they
        > desire?
        > How are queries done in a RESTful manner?
        >
        > Below are some thoughts that I have on this issue.
        >
        > I believe that the REST model can be simply summed up as:
        >
        > "A Web site is composed of resources. A Web site should provide
        > a URL to
        > each resource and enable the exchange, updating and deleting of
        > resources".
        >
        > Thus, with REST it is always an exchange of resources and nothing else.
        >
        > So when we start talking about a user filling in a form we are either
        > talking about a "form resource" or we are breaking away from the
        > REST model. If we are talking about a "form resource" then how would
        > it fit into the above mission resource hierarchy?
        >
        > I believe that it is not appropriate in REST to talk about
        > forms. Instead, we should talk about resources.
        >
        > I believe that with the REST model the idea of issuing queries doesn't
        > make sense. With REST we exchange resources, not queries.
        >
        > That said, I understand the desire to enable a user to query to a Web
        > site for information such as "what aircraft carry Bomb1?".
        >
        > One solution is: this is a user processing issue, not a Web site
        > resource issue, so it is outside the scope of REST. In other words,
        > if a user wants to know what aircraft carry Bomb1 then it is up to the
        > user to retrieve each aircraft resource and do processing on each
        > aircraft resource to determine if it carries Bomb1.
        >
        > That's not a particularly satisfying solution. Perhaps there a way to
        > rephrase the question so that it involves an exchange of resources,
        > rather than a query exchange?
        >
        > I would appreciate hearing your thoughts on this issue. /Roger
        >
        > ------------------------------------------------------------------------
        > *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/>.
        >
        >


        --
        Jan Algermissen
        Consultant & Programmer
        http://jalgermissen.com
      • Vincent D Murphy
        On Fri, 6 May 2005 16:14:30 -0400, Roger L. Costello ... Have a Bomb1 resource, which has links to (a) all aircraft that carry it. (b) all instances of
        Message 3 of 20 , May 6, 2005
        • 0 Attachment
          On Fri, 6 May 2005 16:14:30 -0400, "Roger L. Costello"
          <costello@...> said:
          > "Tell me all the Aircraft that carry Bomb1"

          Have a Bomb1 resource, which has links to
          (a) all aircraft that carry it.
          (b) all 'instances' of Bomb1

          It depends on whether you are talking about
          a particular bomb, or a kind of bomb.

          However I'm not sure about compound queries.
        • S. Mike Dierken
          ... REST doesn t encompass implied hierarchical relationships between resources, just explicit linked relationships (hypertext). ... It s not really the
          Message 4 of 20 , May 6, 2005
          • 0 Attachment
             
            > By implementing this hierarchy [...]
            > This is, of course, standard REST.
            REST doesn't encompass implied hierarchical relationships between resources, just explicit linked relationships (hypertext).
             
            > how would the Web site support the many kinds of queries that a user might want to make
            > "Tell me all the Aircraft that carry Bomb1"
            It's not really the queries that are important, but the results (minor point, I know).
            Giving identity to each and every interesting result is the first step. Returning a representation of those identified results are how a Web site supports all the queries a user might want to make. That's all there is to it - that's the integration point.
             
            However, the way the client app acquires that identifier is the next interesting part - hyperlinking is one way, but not that great with an enormous numbers of resources. Constructing that identifier is another way - which is what you are describing. (I've a feeling we've all heard this before). HTML Forms are a simple description of how to construct that resource identifier. There can be other ways to describe how to construct identifiers - like the OpenSearch stuff from A9.
             
            > The Web site parses the form to extract the query, processes it, and returns the results to the user.
            The client app parses the form, not the site. It does this in order to determine the rules for constructing the resource identifer - and those rules imply user interaction. It's usually a really simple name/value pair kind of interaction, but sometimes it's an interactive graphic where a user's mouse click provides coordinates as inputs to generate a resource identifier. (Someday someone will buy a clue and go crazy with defining new widgets for use in a browser.) The browser constructs the resource identifier then retrieves the specified results.
             
            > How can a Web site possibly provide a form for every conceivable kind of query? 
            > It would be impossible to anticipate every kind of query that users might want to make.
            That's the job of a Web site though - anticipate what information users want and make it easily accessible. Not all access is required to go through a query - the site can simply use hyperlinks on pages. Those hyperlinks can be put in context where a person (or a machine) can understand what kind of results they point to. This is the 'information architecture' aspect of Web design - when to use categorized links and when to use user input based search.
             
             
            > So when we start talking about a user filling in a form we are either talking about a "form resource" or we
            > are breaking away from the REST model
            Not at all. A form is merely a way to generate a resource identifer based on user input. The page that has the form to be filled in is a 'help me locate a resource' type of resource. Pages full of links and explanatory text are also 'resource locator' resources.
             
            > If we are talking about a "form resource" then how would it fit into the above mission resource hierarchy?
            The hierarchy of names in the example shouldn't restrict how users can search for information - like you've mentioned, ad hoc searching should be possible. I don't think a page with a form on it has to be a resource distinct from any of the others. Each representation (web page) can have multiple exit points - some as simple hyperlinks, some as search forms, possibly multiple seach forms on a single page.
             
            > I believe that it is not appropriate in REST to talk about forms. 
            It's very appropriate to talk about forms. They are an assistant to hyperlinking. They can also be considered a 'service description language' (in the same way that Perl is considered by some to be a programming language).
             
            > I believe that with the REST model the idea of issuing queries doesn't make sense.
            Very very true. A client doesn't 'issue a query' - it retrieves results.
             
            > One solution is: this is a user processing issue, not a Web site resource issue, so it is outside the scope of REST.
            This is indeed a user processing issue, and to be useful on the Web it is a good idea to be RESTful.
             
            >In other words, if a user wants to know what aircraft carry Bomb1 then it is up to the user to retrieve each
            > aircraft resource and do processing on each aircraft resource to determine if it carries Bomb1.
            If the designer of the Website did not consider that kind of use, then the poor audience has no choice. The interesting thing is that it is still possible, just boring. But spiders don't get bored.
            However, if the website designer considered this use case, then they can design the resource space to include this kind of result.
             
             
          • Jeffrey Winter
            Roger, I m curious if these questions were triggered by Adam Bosworth s Web of Data presentation, Summary:
            Message 5 of 20 , May 7, 2005
            • 0 Attachment
              Roger,

              I'm curious if these questions were triggered by Adam Bosworth's
              "Web of Data" presentation,

              Summary: http://www.onlamp.com/pub/a/onlamp/2005/04/22/bosworth.html
              Slides: http://www.webratio.com/images/20050408Bosworth.pps

              because after reading these, I was left with similar thoughts.

              See especially the slides "Queries" and "Changes from normal queries."

              He seems to be advocating for a simpler view of data with some
              reasonable set of metadata (RSS/Atom being a good first
              approximation) that can be used to gather data "sloppily." I assume
              then, that more complex analysis (i.e., the equivalent of sub-queries,
              joins, etc.)
              would be the responsibility of the client (which seems to underlie what
              you are suggesting.)

              I don't think that this necessarily goes against the principles of REST
              per se; complex XPath expressions could always be encoded as URLs in
              some manner to provide the sort of complex joins you are talking about.
              I believe Bosworth is saying that supporting that kind of functionality
              simply won't scale massively because the amount of information would need
              to be collected in one place. In the presentation he asks, "what do you
              do if Oracle isn't big enough?" By simplifying what is being stored, there
              are opportunities to scale linearly much more easily (but again, I assume
              that this means some burden is shifted to the client.)

              I actually think he's correct that RSS/Atom is becoming the standard
              "Noun" format that is the subject of the HTTP "Verbs" (with proxies
              and other intermediaries becoming the "Adverbs" I guess.)

              I'd be curious to hear what others think of this.

              Thanks,

              - Jeff







              ----- Original Message -----
              From: "Roger L. Costello" <costello@...>
              To: <rest-discuss@yahoogroups.com>
              Sent: Friday, May 06, 2005 4:14 PM
              Subject: [rest-discuss] The role of queries in REST?


              Hi Folks,

              My question is with regards to the role of a Web site in supporting queries.
              Let me give an example to demonstrate what I mean.

              Suppose that a Web site implements this "hierarchical model of resources"
              for a bombing mission:

              Mission
              Plan1
              ...
              Plan2
              Aircraft
              AA36
              ...
              BB06
              Payload
              Bomb1
              ...
              Bomb2
              Fuze5

              By implementing this hierarchy the Web site gives users the ability to get
              any resource by simply composing a URL, where "/" is used to express a
              parent-child relationship in the resource hierarchy. For example, to obtain
              the AA36 aircraft resource in Plan2 the user issues this URL:

              <http://[hostname]/Mission/Plan2/Aircraft/AA36>
              http://[hostname]/Mission/Plan2/Aircraft/AA36

              This is, of course, standard REST.

              Now consider this problem: how would the Web site support the many kinds of
              queries that a user might want to make, e.g.,

              "Tell me all the Aircraft that carry Bomb1"

              The first approach that comes to mind is for the Web site to make available
              a "form" that the user can retrieve, fill in, and return. The Web site
              parses the form to extract the query, processes it, and returns the results
              to the user.

              However, there is a problem with this approach. There are virtually
              infinitely many different kinds of queries that users may want to make.
              How can a Web site possibly provide a form for every conceivable kind of
              query? It would be impossible to anticipate every kind of query that users
              might want to make.

              More importantly, I believe that focusing on "forms" is missing the point of
              REST.

              Let me now restate my original question:

              What is the role of queries in a REST-based system? How can a Web site
              give
              users the ability to retrieve the kinds of custom data that they desire?

              How are queries done in a RESTful manner?

              Below are some thoughts that I have on this issue.

              I believe that the REST model can be simply summed up as:

              "A Web site is composed of resources. A Web site should provide a URL
              to
              each resource and enable the exchange, updating and deleting of
              resources".

              Thus, with REST it is always an exchange of resources and nothing else.

              So when we start talking about a user filling in a form we are either
              talking about a "form resource" or we are breaking away from the REST model.
              If we are talking about a "form resource" then how would it fit into the
              above mission resource hierarchy?

              I believe that it is not appropriate in REST to talk about forms. Instead,
              we should talk about resources.

              I believe that with the REST model the idea of issuing queries doesn't make
              sense. With REST we exchange resources, not queries.

              That said, I understand the desire to enable a user to query to a Web site
              for information such as "what aircraft carry Bomb1?".

              One solution is: this is a user processing issue, not a Web site resource
              issue, so it is outside the scope of REST. In other words, if a user wants
              to know what aircraft carry Bomb1 then it is up to the user to retrieve each
              aircraft resource and do processing on each aircraft resource to determine
              if it carries Bomb1.

              That's not a particularly satisfying solution. Perhaps there a way to
              rephrase the question so that it involves an exchange of resources, rather
              than a query exchange?

              I would appreciate hearing your thoughts on this issue. /Roger
            • Dave Pawson
              ... That said, I understand the desire to enable a user to query to a Web site for information such as what aircraft carry Bomb1? . ... *An* approach Roger.
              Message 6 of 20 , May 7, 2005
              • 0 Attachment
                On Fri, 2005-05-06 at 16:14 -0400, Roger L. Costello wrote:
                > Hi Folks,
                >
                > My question is with regards to the role of a Web site in supporting
                > queries. Let me give an example to demonstrate what I mean.
                >
                > Suppose that a Web site implements this "hierarchical model of
                > resources" for a bombing mission:
                >
                > Mission
                > Plan1
                > ...
                > Plan2
                > Aircraft
                > AA36
                > ...
                > BB06
                > Payload
                > Bomb1
                > ...
                > Bomb2
                > Fuze5

                >

                That said, I understand the desire to enable a user to query to a Web
                site for information such as "what aircraft carry Bomb1?".
                > That's not a particularly satisfying solution. Perhaps there a way to
                > rephrase the question so that it involves an exchange of resources,
                > rather than a query exchange?
                >
                > I would appreciate hearing your thoughts on this issue.

                *An* approach Roger.
                Perhaps just a variant view of a query?
                The url is 'missing' some bits.

                /mission/*/X/Payload/Bomb1

                The question is, what is X?

                I know I can capture the url sought from the get,
                so perhaps I can return a list of url's for which X is valid?

                regards DaveP
              • Vincent D Murphy
                On Sat, 7 May 2005 09:00:01 -0400, Jeffrey Winter ... I agree. My interpretation is that he is advocating a simplified interface and format to data on the
                Message 7 of 20 , May 8, 2005
                • 0 Attachment
                  On Sat, 7 May 2005 09:00:01 -0400, "Jeffrey Winter"
                  <JeffreyWinter@...> said:
                  > I don't think that this necessarily goes against the principles of REST
                  > per se;

                  I agree.

                  My interpretation is that he is advocating a simplified interface and
                  format to data on the web. Simpler than what we use for databases. The
                  result is essentially a lowest common denominator. The results are in
                  RSS, the protocol is HTTP.

                  There is no doubt that database binary wire formats are definitely past
                  their sell-by date. Think of how many database drivers we could dispense
                  with if they all used one wire format.

                  He doesn't say much about queries, but name-value pairs
                  (application/x-www-form-urlencoded as used by HTML forms) or Google (no
                  real syntax) seem to be as far as it goes. Again, lowest common
                  denominator.

                  I don't think anything he is proposing contradicts the REST
                  architectural style either.

                  > complex XPath expressions could always be encoded as URLs in
                  > some manner to provide the sort of complex joins you are talking about.

                  Or, maybe the indexes necessary to make joins work will be maintained by
                  third party intermediaries (Google?), and they would be the servers to
                  query. These third parties might run spiders specialised on particular
                  XML or RDF namespaces or schemas.

                  [snip]
                  > I actually think he's correct that RSS/Atom is becoming the standard
                  > "Noun" format that is the subject of the HTTP "Verbs" (with proxies
                  > and other intermediaries becoming the "Adverbs" I guess.)

                  I see URIs as the nouns, and RSS/Atom as more of a structure to hang
                  metadata on.

                  I agree that HTTP methods are verbs, but I wonder whether
                  intermediaries-as-adverbs is stretching the analogy a bit. :)
                • Nic Ferrier
                  ... URIs are only the noun of the nouns. The nouns themselves are the resources to which the URIs point. I personally think that RSS is a really good noun
                  Message 8 of 20 , May 8, 2005
                  • 0 Attachment
                    "Vincent D Murphy" <vdm@...> writes:

                    > [snip]
                    >> I actually think he's correct that RSS/Atom is becoming the standard
                    >> "Noun" format that is the subject of the HTTP "Verbs" (with proxies
                    >> and other intermediaries becoming the "Adverbs" I guess.)
                    >
                    > I see URIs as the nouns, and RSS/Atom as more of a structure to hang
                    > metadata on.

                    URIs are only the noun of the nouns. The nouns themselves are the
                    resources to which the URIs point.

                    I personally think that RSS is a really good noun format for many of
                    the list of URIs resouces that we talk about in REST.


                    > I agree that HTTP methods are verbs, but I wonder whether
                    > intermediaries-as-adverbs is stretching the analogy a bit. :)

                    I agree too.

                    But then I can never remember what an adverb is /8->



                    Nic
                  • Roger L. Costello
                    Hi Folks, Many thanks for your replies. I am still assimilating your comments. A question arose in my mind as I read the comments from Mike and Jan: To what
                    Message 9 of 20 , May 10, 2005
                    • 0 Attachment
                      Hi Folks,
                       
                      Many thanks for your replies.  I am still assimilating your comments.
                       
                      A question arose in my mind as I read the comments from Mike and Jan:
                       
                      To what level should the "rules for constructing resource identifiers" be hidden from clients?
                       
                      Allow me to elaborate upon this question.
                       
                      Consider these fundamental REST tenets:
                       
                      1. A Web site is comprised of resources.
                       
                      2. Each resource has an identifier, i.e., a URL
                       
                      3. A client uses an identifier to retrieve a resource. 
                       
                      3.1 Corollary: if a client doesn't have the identifier then he can't get the resource.
                       
                      4. "A form is a way to generate a resource identifier based on user input." [Mike]
                       
                      Jan spoke about the importance of ensuring that clients are decoupled from a Web site.  [Paraphrasing] If a client uses information about how a Web site structures its resources (i.e., the Web site's domain model) then the client is coupling itself to the Web site - if the Web site reorganizes its resources then the client's applications will break.  [Jan, have I summarized your argument correctly?]
                       
                      Isn't there a paradox here?  On the one hand, identifiers to resources must be made available, else clients can't access the resources.  On the other hand too much knowledge of resource identifiers leads to coupling.
                       
                      In my original message I proposed that a Web site make visible to clients this hierarchical model of resources:
                       
                      Mission
                          Plan1
                               ...
                          Plan2
                              Aircraft
                                  AA36
                                      ...
                                  BB06
                                      Payload
                                          Bomb1
                                              ...
                                          Bomb2
                                              Fuze5
                       
                      My intent is that clients can utilize this hierarchical model to construct resource identifiers - a client can retrieve any resource in this hierarchy by simply creating an XPath expression to the desired resource.  For example, to retrieve BB06 in Plan2 the client would construct this identifier:
                       
                       
                      Has this Web site exposed too much of its model?  Have I exposed too much of the rules for constructing resource identifiers?  Will clients become dangerously coupled? 
                       
                      To what level should the rules for constructing identifiers be exposed by a Web site?  To what level should they be hidden?  Is it the purpose of forms to shield clients from the rules for constructing identifiers?  /Roger
                    • Jan Algermissen
                      ... Close enough, yes. Though I would not use the term Web site , since it (IMHO) sort of implies resources are pages . ... Hmm...no, I don t think so. I was
                      Message 10 of 20 , May 10, 2005
                      • 0 Attachment
                        Roger L. Costello wrote:

                        >
                        > Jan spoke about the importance of ensuring that clients are decoupled
                        > from a Web site. [Paraphrasing] If a client uses information about
                        > how a Web site structures its resources (i.e., the Web site's domain
                        > model) then the client is coupling itself to the Web site - if the Web
                        > site reorganizes its resources then the client's applications will
                        > break. [Jan, have I summarized your argument correctly?]

                        Close enough, yes. Though I would not use the term 'Web site', since it
                        (IMHO) sort of implies 'resources are pages'.

                        >
                        > Isn't there a paradox here? On the one hand, identifiers to resources
                        > must be made available, else clients can't access the resources. On
                        > the other hand too much knowledge of resource identifiers leads to
                        > coupling.

                        Hmm...no, I don't think so. I was talking about using domain model
                        knowledge for constructing queries, not
                        for constructing identifiers. Clients have to treat URIs as being
                        opaque, they must not *construct* URIs but may
                        only use URIs found in the retreived representations. (modulo GET forms,
                        aka Mark's 'indexable resources').

                        > In my original message I proposed that a Web site make visible to
                        > clients this hierarchical model of resources:
                        >
                        > Mission
                        > Plan1
                        > ...
                        > Plan2
                        > Aircraft
                        > AA36
                        > ...
                        > BB06
                        > Payload
                        > Bomb1
                        > ...
                        > Bomb2
                        > Fuze5
                        >
                        > My intent is that clients can utilize this hierarchical model to
                        > construct resource identifiers -

                        REST does not 'allow' any kind of identifier construction (IMHO).

                        > a client can retrieve any resource in this hierarchy by simply
                        > creating an XPath expression to the desired resource. For example, to
                        > retrieve BB06 in Plan2 the client would construct this identifier:
                        >
                        > http://[hostname]/mission/plan2/aircraft/BB06
                        > <http://%5Bhostname%5D/mission/plan2/aircraft/BB06>

                        That would mean that there is some kind of semantic alignment of the
                        hierarchy relationship expressed in the example
                        representation (the semantics being defined in its MIME type) and the
                        (assumed?) hierarchy of path's in URIs.
                        I doubt that this can be derived from REST. What do others think?

                        >
                        > Has this Web site exposed too much of its model? Have I exposed too
                        > much of the rules for constructing resource identifiers? Will clients
                        > become dangerously coupled?

                        Definitely. Think about how persistent the constructed URIs is, given
                        that it has not been uttered by the server but constructed
                        by the client. If the server changes the hierarchy, the URI becomes sort
                        of meaningless or wrong.

                        >
                        > To what level should the rules for constructing identifiers be exposed
                        > by a Web site?

                        There ain't no constructing of identifiers....

                        > To what level should they be hidden? Is it the purpose of forms to
                        > shield clients from the rules for constructing identifiers?

                        I wonder if GET forms are RESTful at all? Are they?

                        Jan



                        > /Roger
                        >
                        > ------------------------------------------------------------------------
                        > *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/>.
                        >
                        >


                        --
                        Jan Algermissen http://www.jalgermissen.com
                        Consultant & Programmer http://www.tugboat.de
                      • Vincent D Murphy
                        On Tue, 10 May 2005 15:42:00 -0400, Roger L. Costello ... This issue is explored quite well in this article: Constructing or Traversing URIs?
                        Message 11 of 20 , May 10, 2005
                        • 0 Attachment
                          On Tue, 10 May 2005 15:42:00 -0400, "Roger L. Costello"
                          <costello@...> said:
                          > To what level should the "rules for constructing resource identifiers" be
                          > hidden from clients?

                          This issue is explored quite well in this article:

                          Constructing or Traversing URIs?
                          http://www.xml.com/pub/a/2005/04/06/restful.html
                        • Roy T. Fielding
                          ... That s not true. REST only requires that the representations supply the identifiers. That doesn t prevent the representation from dynamically
                          Message 12 of 20 , May 10, 2005
                          • 0 Attachment
                            On May 10, 2005, at 1:43 PM, Jan Algermissen wrote:

                            > REST does not 'allow' any kind of identifier construction (IMHO).

                            That's not true. REST only requires that the representations
                            supply the identifiers. That doesn't prevent the representation
                            from dynamically constructing the identifier in accordance with
                            whatever rules are standard for the media type (e.g., HTML has
                            forms, server-side image-maps, and Javascript -- all of which
                            can generate very RESTful transitions to the next state).

                            ....Roy
                          • Jan Algermissen
                            ... Oops...yes, I was obviously making a stupid statement there... Sorry for causing confusion. So then....given some representation
                            Message 13 of 20 , May 10, 2005
                            • 0 Attachment
                              Roy T. Fielding wrote:

                              > On May 10, 2005, at 1:43 PM, Jan Algermissen wrote:
                              >
                              >> REST does not 'allow' any kind of identifier construction (IMHO).
                              >
                              >
                              > That's not true. REST only requires that the representations
                              > supply the identifiers. That doesn't prevent the representation
                              > from dynamically constructing the identifier in accordance with
                              > whatever rules are standard for the media type (e.g., HTML has
                              > forms, server-side image-maps, and Javascript -- all of which
                              > can generate very RESTful transitions to the next state).

                              Oops...yes, I was obviously making a stupid statement there...
                              Sorry for causing confusion.

                              So then....given some representation

                              <root base="http://ex.org/foo/base/">
                              <item id="mission1">
                              <hasPart>
                              <item id="plan1">
                              <hasPart>
                              <item id="aircraft-AA36">
                              </hasPart>
                              </item>
                              </hasPart>
                              </item>
                              </root>

                              having a MIME type that defines the neccessary 'construction semantics'
                              it would be RESTful
                              to construct the URI

                              http://ex.org/foo/base/mission1/plan1/aircraft-AA36

                              for the innermost item.

                              Is that what you asked, Roger?


                              Jan





                              >
                              > ....Roy
                              >
                              >


                              --
                              Jan Algermissen http://www.jalgermissen.com
                              Consultant & Programmer http://www.tugboat.de
                            • Dave Pawson
                              ... It seemed to me a fairly clear solution to the problem that Roger posed. Especially since he painted a clear hierarchy of resource information. ... Could I
                              Message 14 of 20 , May 10, 2005
                              • 0 Attachment
                                On Tue, 2005-05-10 at 22:43 +0200, Jan Algermissen wrote:


                                > > My intent is that clients can utilize this hierarchical model to
                                > > construct resource identifiers -
                                >
                                > REST does not 'allow' any kind of identifier construction (IMHO).
                                >
                                > > a client can retrieve any resource in this hierarchy by simply
                                > > creating an XPath expression to the desired resource. For example, to
                                > > retrieve BB06 in Plan2 the client would construct this identifier:
                                > >
                                > > http://[hostname]/mission/plan2/aircraft/BB06
                                > > <http://%5Bhostname%5D/mission/plan2/aircraft/BB06>
                                >
                                > That would mean that there is some kind of semantic alignment of the
                                > hierarchy relationship expressed in the example
                                > representation (the semantics being defined in its MIME type) and the
                                > (assumed?) hierarchy of path's in URIs.
                                > I doubt that this can be derived from REST. What do others think?

                                It seemed to me a fairly clear solution to the problem that Roger posed.
                                Especially since he painted a clear hierarchy of resource information.

                                >
                                > >
                                > > Has this Web site exposed too much of its model? Have I exposed too
                                > > much of the rules for constructing resource identifiers? Will clients
                                > > become dangerously coupled?
                                >
                                > Definitely. Think about how persistent the constructed URIs is, given
                                > that it has not been uttered by the server but constructed
                                > by the client. If the server changes the hierarchy, the URI becomes sort
                                > of meaningless or wrong.

                                Could I redefine that as 'the model has changed'? Implied temporal
                                coupling yes, but change happens.

                                That restricts the query response to some (indeterminate) timeframe,
                                during which we rely on the host not to change the structure of the
                                website. Seems realistic to me.

                                regards DaveP
                              • S. Mike Dierken
                                ... I think Jan meant that the client shouldn t be hardcoded to assume the location of certain things - like looking for resource identifiers such as
                                Message 15 of 20 , May 10, 2005
                                • 0 Attachment
                                  > Isn't there a paradox here?  On the one hand, identifiers to resources must be made available, else clients can't access the
                                  > resources.  On the other hand too much knowledge of resource identifiers leads to coupling.
                                  I think Jan meant that the client shouldn't be hardcoded to assume the location of certain things - like looking for resource identifiers such as robots.txt, favicon.gif, etc. Having a level of indirection through a description language allows one client to work with many sites - which is the goal of decoupling
                                   
                                  > For example, to retrieve BB06 in Plan2 the client would construct this identifier:
                                  > Has this Web site exposed too much of its model? 
                                  > Have I exposed too much of the rules for constructing resource identifiers?  Will clients become dangerously coupled? 
                                  If you don't use a description language, then it's all hard-coded and site-specific. If you create a description of how to access the resources, and that description might actually be used by lots of sites, then it's a bit more decoupled.
                                   
                                  I think that pure linking is an easier and very generic approach, and that constructing URIs is flexible but a little less generic. Both are valuable. There might be more flexible approaches, but my guess is they would be less generic - meaning they would be more tightly coupled.
                                   
                                   
                                   
                                   
                                • Bornholtz, Tim
                                  ... So is there a standard description language being adopted? I know that Tim Bray suggested one recently (
                                  Message 16 of 20 , May 11, 2005
                                  • 0 Attachment
                                    RE: [rest-discuss] The role of queries in REST?

                                    >> Isn't there a paradox here?  On the one hand, identifiers to resources must >be made available, else clients can't access the

                                    >> resources.  On the other hand too much knowledge of resource identifiers >leads to coupling.
                                    >I think Jan meant that the client shouldn't be hardcoded to assume the >location of certain things - like looking for resource identifiers such as  >robots.txt, favicon.gif, etc. Having a level of indirection through a >description language allows one client to work with many sites - which is the >goal of decoupling


                                    So is there a standard description language being adopted?  I know that Tim Bray suggested one recently ( http://www.tbray.org/ongoing/When/200x/2005/05/03/SMEX-D ).  If eveyone creates their own way to describe the available services then each client is still somewhat tightly coupled to the implementation.

                                    Thanks,
                                    Tim





                                  • Jan Algermissen
                                    ... One fascinating thing about REST is IMHO that a description language does not make sense, because it s the representations (obtained at runtime) that tell
                                    Message 17 of 20 , May 11, 2005
                                    • 0 Attachment
                                      Bornholtz, Tim wrote:

                                      > >> Isn't there a paradox here? On the one hand, identifiers to
                                      > resources must >be made available, else clients can't access the
                                      > >> resources. On the other hand too much knowledge of resource
                                      > identifiers >leads to coupling.
                                      > >I think Jan meant that the client shouldn't be hardcoded to assume
                                      > the >location of certain things - like looking for resource
                                      > identifiers such as >robots.txt, favicon.gif, etc. Having a level of
                                      > indirection through a >description language allows one client to work
                                      > with many sites - which is the >goal of decoupling
                                      >
                                      >
                                      > So is there a standard description language being adopted?
                                      >
                                      One fascinating thing about REST is IMHO that a description language
                                      does not make sense, because it's the representations
                                      (obtained at runtime) that tell the client what options (==hyperlinks)
                                      there are to proceed through the application. There is
                                      just nothing to be described pre-runtime.

                                      Jan


                                      > I know that Tim Bray suggested one recently (
                                      > http://www.tbray.org/ongoing/When/200x/2005/05/03/SMEX-D ). If
                                      > eveyone creates their own way to describe the available services then
                                      > each client is still somewhat tightly coupled to the implementation.
                                      >
                                      > Thanks,
                                      > Tim
                                      >
                                      >
                                      >
                                      >
                                      >
                                      >
                                      > ------------------------------------------------------------------------
                                      > *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/>.
                                      >
                                      >


                                      --
                                      Jan Algermissen http://www.jalgermissen.com
                                      Consultant & Programmer http://www.tugboat.de
                                    • Josh Sled
                                      ... There does seem to be a requirement for a description as both documentation and tooling-input (to create client-side access stubs) for the
                                      Message 18 of 20 , May 11, 2005
                                      • 0 Attachment
                                        On Wed, 2005-05-11 at 14:38 +0200, Jan Algermissen wrote:
                                        > One fascinating thing about REST is IMHO that a description language
                                        > does not make sense, because it's the representations
                                        > (obtained at runtime) that tell the client what options (==hyperlinks)
                                        > there are to proceed through the application. There is
                                        > just nothing to be described pre-runtime.

                                        There does seem to be a requirement for a description as both
                                        documentation and tooling-input (to create client-side access stubs) for
                                        the software-accessing-an-API case.

                                        It's useful to describe an application state-space apart from its
                                        execution, especially as client software without a human operator can't
                                        respond well to (semantic) changes, and must be (well, it's easiest to
                                        be) built with a hard expectation of the server.

                                        ...jsled

                                        --
                                        http://asynchronous.org/ - `a=jsled; b=asynchronous.org; echo ${a}@${b}`
                                      • Jan Algermissen
                                        ... Yes, I know what you mean (and I have worked on this myself), but....would it be RESTful to implement client behaviour based on knowledge beyond the
                                        Message 19 of 20 , May 11, 2005
                                        • 0 Attachment
                                          Josh Sled wrote:

                                          >On Wed, 2005-05-11 at 14:38 +0200, Jan Algermissen wrote:
                                          >
                                          >
                                          >>One fascinating thing about REST is IMHO that a description language
                                          >>does not make sense, because it's the representations
                                          >>(obtained at runtime) that tell the client what options (==hyperlinks)
                                          >>there are to proceed through the application. There is
                                          >>just nothing to be described pre-runtime.
                                          >>
                                          >>
                                          >
                                          >There does seem to be a requirement for a description as both
                                          >documentation and tooling-input (to create client-side access stubs) for
                                          >the software-accessing-an-API case.
                                          >
                                          >
                                          Yes, I know what you mean (and I have worked on this myself),
                                          but....would it be RESTful to
                                          implement client behaviour based on knowledge beyond the semantics of a
                                          MIME type dfinition?

                                          E.g. would it be RESTful to code a client app to GET
                                          http://www.google.de/search?q=foo
                                          and *after* that expect to receive a list of hits; that is to hard-wire
                                          the expectation that the
                                          server will offer such a list of possible subsequent state changes? What
                                          if the state machine
                                          (that is the web app) changes?

                                          OTH, could the behaviour be part of the semantics of a MIME type?

                                          ------

                                          BTW, I would like to see such a description language to generate
                                          *server-side* stubs to
                                          ease the process of bringing legacy apps into REST space....

                                          -------

                                          And....it is an interesting issue (damn, someone give me more time in a
                                          day :-( ) how the
                                          state machine of a web app relates to process/workflow management
                                          (essentially the web apps
                                          state machine controls the possible actions of the client[1]) and to
                                          pi-calculus on the theoretical
                                          level....

                                          [1] ..and can even differentiate between actor roles given the user
                                          information of the HTTP request.

                                          Jan



                                          >It's useful to describe an application state-space apart from its
                                          >execution, especially as client software without a human operator can't
                                          >respond well to (semantic) changes, and must be (well, it's easiest to
                                          >be) built with a hard expectation of the server.
                                          >
                                          >...jsled
                                          >
                                          >
                                          >


                                          --
                                          Jan Algermissen http://www.jalgermissen.com
                                          Consultant & Programmer http://www.tugboat.de
                                        • mdkersey
                                          ... comments. ... identifiers be ... get the ... ================================= Yes, but not a problem The client has the URL of _another_ resource that
                                          Message 20 of 20 , May 21, 2005
                                          • 0 Attachment
                                            --- In rest-discuss@yahoogroups.com, "Roger L. Costello"
                                            <costello@m...> wrote:
                                            > Hi Folks,
                                            >
                                            > Many thanks for your replies. I am still assimilating your
                                            comments.
                                            > A question arose in my mind as I read the comments from Mike and
                                            Jan:
                                            > To what level should the "rules for constructing resource
                                            identifiers" be
                                            > hidden from clients?
                                            >
                                            > Allow me to elaborate upon this question.
                                            > Consider these fundamental REST tenets:
                                            > 1. A Web site is comprised of resources.
                                            > 2. Each resource has an identifier, i.e., a URL
                                            > 3. A client uses an identifier to retrieve a resource.
                                            > 3.1 Corollary: if a client doesn't have the identifier then he can't
                                            get the
                                            > resource.

                                            =================================
                                            Yes, but not a problem The client has the URL of _another_ resource
                                            that can get the resource he wants.

                                            So while a URL is often a static page, it also can be a program that
                                            asks the user questions. In that case the client _must_ know how to
                                            access the URL of the program. So what you say is true, but that is no
                                            barrier to information access.

                                            [It's like real life: I may not know how to program in Common Lisp,
                                            but if i have a question I know that I can ask Joe Smith (Common Lisp
                                            guru) for information. He will then ask me questions and give me the
                                            answer.]

                                            IOW the client need not know _how_ URLs are constructed, but needs to
                                            know the appropriate URL(s) to get information. The client fills out a
                                            form by describing what he wants, a program on the web server accepts
                                            that form and returns an answer. The program may optionally assign a
                                            bookmarkable URL to that resource.
                                            =================================

                                            > 4. "A form is a way to generate a resource identifier based on user
                                            input."
                                            > [Mike]
                                            >
                                            > Jan spoke about the importance of ensuring that clients are
                                            decoupled from a
                                            > Web site. [Paraphrasing] If a client uses information about how a
                                            Web site
                                            > structures its resources (i.e., the Web site's domain model) then
                                            the client
                                            > is coupling itself to the Web site - if the Web site reorganizes its
                                            > resources then the client's applications will break. [Jan, have I
                                            > summarized your argument correctly?]
                                            >
                                            > Isn't there a paradox here? On the one hand, identifiers to
                                            resources must
                                            > be made available, else clients can't access the resources. On the
                                            other
                                            > hand too much knowledge of resource identifiers leads to coupling.

                                            =================================
                                            Yes, but remember the definition of a paradox. IOW this is not a
                                            logical contradiction. It is a warning to construct sites so they can
                                            be changed w/o interrupting the user.
                                            =================================

                                            > In my original message I proposed that a Web site make visible to
                                            clients
                                            > this hierarchical model of resources:
                                            > Mission
                                            > Plan1
                                            > ...
                                            > Plan2
                                            > Aircraft
                                            > AA36
                                            > ...
                                            > BB06
                                            > Payload
                                            > Bomb1
                                            > ...
                                            > Bomb2
                                            > Fuze5
                                            >
                                            > My intent is that clients can utilize this hierarchical model to
                                            construct
                                            > resource identifiers - a client can retrieve any resource in this
                                            hierarchy
                                            > by simply creating an XPath expression to the desired resource. For
                                            > example, to retrieve BB06 in Plan2 the client would construct this
                                            > identifier:
                                            >
                                            > http://[hostname]/mission/plan2/aircraft/BB06
                                            >
                                            > Has this Web site exposed too much of its model? Have I exposed too
                                            much of
                                            > the rules for constructing resource identifiers? Will clients
                                            become
                                            > dangerously coupled?

                                            =================================
                                            If it is adequate to the users and you don't change the site, there
                                            should be no problems. But see below.

                                            > To what level should the rules for constructing identifiers be
                                            exposed by a
                                            > Web site? To what level should they be hidden? Is it the purpose
                                            of forms
                                            > to shield clients from the rules for constructing identifiers?

                                            URIs should be opaque. You may want to look at
                                            "The Opacity Axiom"
                                            http://www.w3.org/DesignIssues/Axioms.html#opaque

                                            The opacity axiom apparently does not apply to the querystring portion
                                            of a URL.

                                            One concern with non-opaque URLs (or the non-opaque portion of URLs in
                                            the case of querystring variables) is security. E.g., in an intranet,
                                            upon seeing their employee number in a URL, the first thing employees
                                            will do is cut and paste their boss's or friend's employee number and
                                            try to access info they shouldn't. Non-opaque URIs seem to promote
                                            cracking behavior in everyone.

                                            But many sites have URLs that are (at least partially) not opaque and,
                                            since they never change and are securely managed, are very happy. And,
                                            if there is a change, you can always write server-side code that maps
                                            the old URLs to new ones, either transparently or not.
                                            =================================
                                          Your message has been successfully submitted and would be delivered to recipients shortly.