5060Re: The role of queries in REST?
- May 21, 2005--- In email@example.com, "Roger L. Costello"
> Hi Folks,comments.
> Many thanks for your replies. I am still assimilating your
> A question arose in my mind as I read the comments from Mike andJan:
> To what level should the "rules for constructing resourceidentifiers" be
> hidden from clients?get the
> 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
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 userinput."
> [Mike]decoupled from a
> Jan spoke about the importance of ensuring that clients are
> Web site. [Paraphrasing] If a client uses information about how aWeb site
> structures its resources (i.e., the Web site's domain model) thenthe client
> is coupling itself to the Web site - if the Web site reorganizes itsresources must
> 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
> be made available, else clients can't access the resources. On theother
> 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 toclients
> this hierarchical model of resources:construct
> My intent is that clients can utilize this hierarchical model to
> resource identifiers - a client can retrieve any resource in thishierarchy
> by simply creating an XPath expression to the desired resource. Formuch of
> example, to retrieve BB06 in Plan2 the client would construct this
> Has this Web site exposed too much of its model? Have I exposed too
> the rules for constructing resource identifiers? Will clientsbecome
> 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 beexposed by a
> Web site? To what level should they be hidden? Is it the purposeof 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.
- << Previous post in topic