RESTful Web services and DAL

[Doug Tody]

Hi All -

I need to drop this soon and focus on other things for a while (the
Madrid meetings are coming up next week), but one more point first
to follow-on from our discussion of different perspectives below.

REST is defined as an architectural style, but it is often also
promoted as a programming model, defining a resource rather than
object oriented view of things (I think some of the folks involved
in this discussion are promoting REST in this way).

For a long time there has been a big debate in Web-land about SOAP
vs REST, in part because SOAP does not use the Web in a way which is
consistent with REST, but REST is the basic architecture of the Web.
The programming model for SOAP is the Object model, where we execute
methods on an object (yes, SOAP is also about messages, but a remote
method invocation is a type of message).

I would suggest though, that it is possible to use the Web in a way
which is consistent with the REST model which is the basis of the Web,
without necessarily having to adopt REST as the programming model at
all levels (client application, Web middleware, server/servlet).

Hence, for example, it is possible to use the Object model at the
application level, but still be consistent REST at the level of the
Web.  If for the moment we think in terms of applications and ignore
the Web, and compare the Object model and REST as programming models,
there is a pretty good chance that the Object model will work better
for many applications; REST is a pretty low-level ("file-like") model.
Furthermore, we would like to isolate applications from too much
knowledge of the middleware (DCP), to achieve goals such as location
transparency, so that an application can operate upon either local
or remote data, so adopting Web-oriented models at all levels is
probably undesirable in information hiding terms as well.

It is a mistake to focus too much on only the Web/grid protocols;
one needs to look at the overall architecture to optimize the design
of the Web/grid middleware.

The DAL services, and related services such as the Registry, are based
on the Object model from the perspective of a client application or
the service implementation.  DAL at least is also consistent with REST
(functionally if not conceptually) at the level of the Web.  An open
question is to what extent we can continue to achieve this as we add
support for stateful services, asynchrony, messaging, and so forth.

 	- Doug




On Wed, 14 Mar 2007, Doug Tody wrote:

> On Wed, 14 Mar 2007, Guy Rixon wrote:
>
>> On Tue, 13 Mar 2007, Doug Tody wrote:
>>
>>> ...  In this case the Web
>>> goes one step further than Unix, as *merely reading* an executable
>>> file is allowed to transparently execute the file.  GET defines
>>> a syntax which allows the command arguments to be folded into the
>>> command reference as one long string, the URL.  A clever Unix file
>>> system driver could be written to do this same thing.  POST is a more
>>> explicit command invocation, which separates the command arguments
>>> from the command reference.
>>
>> And therein lies the schism. In the web, GET _does not_ "execute a command",
>> ever. It fetches the content of a specific resource, identified by that
>> resource's URI. From the client's viewpoint that content existed before the
>> GET and exists afterwards. The service implementor may choose to generate the
>> content for each resource, but the client _must not_ assume that. If the
>> client can tell the difference between "fetches existing content" and
>> "executes command", then the verb must be POST (or possibly PUT, in special
>> cases). This is central to REST.
>
> This is true - from the point of view of the Web.  The GET is just
> a string which references some resource, the "contents" of which
> are returned to the client.  A well-behaved (RESTful) GET should be
> idempotent; much of the Web machinery depends upon this.
>
> However, taking a slightly broader view, the Web is just middleware which
> follows certain rules.  The client may need to compose the GET URL,
> and the server may need to parse it and execute something.  From the
> client's perspective it may appear that it is composing and invoking a
> method of some sort.  It is true though, that even though the client may
> compose the URL, it doesn't really know if anything gets executed; e.g.,
> according to the rules of the Web, the response could merely be cached.
> All that REST really requires (functionally if not conceptually) is that
> the GET be idempotent.  Then all the scalability, caching, etc. will work
> as intended.
>
> I don't think there is any argument here; we are saying the same thing.
> But one should bear in mind that there are multiple perspectives involved,
> and the Web is not the whole story.
>
> 	- Doug
>