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

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

Expand Messages
  • Jan Algermissen
    May 10, 2005
      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
    • Show all 20 messages in this topic