5013Re: [rest-discuss] The role of queries in REST?
- May 6, 2005Hi 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,
intention is to specify a subset of the entire (indexed) web.
(2) specifying previously unknown resource collections by arbitrarily
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
model to construct the query.
I think (1) perfectly suits REST's application model but (2) doesn't. I
reason is that in case (2) the client makes assumptions about the
are beyond the information it retrives from the server. This is a form
coupling (of the client to the specific domain model). If the domain
the queries break (IMHO the reason why the relational model and OO-model
obstacles in Data Integration/EAI scenarios).
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:
> 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
> 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
> 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:
> * To unsubscribe from this group, send an email to:
> * Your use of Yahoo! Groups is subject to the Yahoo! Terms of
> Service <http://docs.yahoo.com/info/terms/>.
Consultant & Programmer
- << Previous post in topic Next post in topic >>