RESTful Web services and DAL

[Matthew Graham]

Doug Tody wrote:
> On Tue, 13 Mar 2007, Matthew Graham wrote:
>
>> Thanks, Doug, for this really good analogy.
>>
>> Doug Tody wrote:
>>> On Tue, 13 Mar 2007, Doug Tody wrote:
>
> [...]
>
>>> The analogous "execute" operation on the Web is GET or POST, both of
>>> which can execute a command with parameters.  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.
>
>> Except that in proper REST, GET and POST have different consequences 
>> which is why the command arguments should not be folded into the URL.
>
> I would argue that, so long as a fixed URL string (GET) consistently
> returns the same result with the usual REST semantics, then it is
> sufficient to qualify as REST.
>
> There is little point in pushing the theology too far here; what
> matters is why REST is important and what we want to achieve by using
> it, and whether or not a given case achieves this.  Fundamentally a
> URL is a string which references a resource; if it behaves consistent
> with REST, I would say it qualifies as REST.  If the reference has any
> side effects, POST should be used instead.  HTTP GET with parameters
> fundamentally has a dual nature, and it can be viewed both as a call
> to a service operation (at composition time), and as a reference to
> a resource exposed on the Web (by the run time system); the latter
> case can have all the usual REST semantics as regards use of standard
> protocols and tools, caching, etc.
>
> For the sake of avoiding further argument lets agree that this case
> is not REST in the most formal academic sense.  Nonetheless a GET
> of this type can have the same semantics and advantages as REST.
> The only real difference is how the reference is composed and parsed.
Yes, in the most formal case it is not REST. The dual nature of HTTP GET 
is the real problem, though.

    Cheers,

    Matthew