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

Re: [rest-discuss] The role of queries in REST?

Expand Messages
  • 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 1 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 2 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 3 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 4 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 5 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 6 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 7 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.