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.