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

5060Re: The role of queries in REST?

Expand Messages
  • mdkersey
    May 21, 2005
      --- In rest-discuss@yahoogroups.com, "Roger L. Costello"
      <costello@m...> wrote:
      > Hi Folks,
      > Many thanks for your replies. I am still assimilating your
      > A question arose in my mind as I read the comments from Mike and
      > 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

      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
      > [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
      > 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
      > 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
      > resource identifiers - a client can retrieve any resource in this
      > 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
      > 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"

      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.
    • Show all 20 messages in this topic