REST and agents

I have been trying to follow the hundreds of emails on the RESThole 
(sic) and I am impressed about how much heat there is for so little 
light.

However, in the spirit of trying to help I would like to draw a 
comparison between what I understand of this debate is and a similar 
debate going on in a different arena.

In the Intelligent Agent community we have been working for some time 
on a standard communications language -- called FIPA ACL. There are 
some similarities and some significant differences between FIPA ACL and 
HTTP.

1. Like the GET, FIPA ACL defines some standard verbs at the top-level. 
The two most important are INFORM and REQUEST. GET is sort of analogous 
to REQUEST and INFORM is sort of analogous to POST.

Most importantly, as with HTTP/HTML, FIPA ACL expects the `meat' of the 
message to be encoded in a propositional content.

So, for example, to get a stock quote, you might REQUEST the value of 
IBM's stock quote. The `value of IBM's stock quote' is the 
propositional content and the REQUEST communicates your intention. With 
a powerful enough language for expressing the propositional content you 
can do whatever you want; in a way that's exactly analogous to 
HTTP/HTML for browsers.

It should be noted that although FIPA has tried to be agnostic on the 
form of the propositional content I do not believe that that position 
is tenable -- for the same reason that HTTP without HTML is pretty 
useless. In the context of REST-style Web services, this would amount 
to having a standard for GET but no standard for the form of the 
response. I think that this is at the heart of 90% of the flak directed 
at Mark: without such a standard just having GET will get you not very 
far. (He of course disagrees)

2. Suppose that one goes along with GET for a little while? Let us see 
what benefits there might be? I would say that (assuming that you also 
fix a few other issues) you get some additional support for automation. 
Having standard ways of expressing top-level verbs will help, and 
certainly not hinder, many of the potential uses of Web services. Its 
hard to quantify this of course; and I think that most of the benefits 
evaporate unless ...

3. you also have a standard way of encoding the `propositional 
content'. I.e., an analogue of HTML but for Web services. I.e., such a 
content language would allow Web service providers to express their 
specific semantics in a common notation that all Web service clients 
would be expected to `understand' in a hard-wired kind of a way.

This is not the same as XML, SOAP or even WSDL, but something more 
powerful. Because, in a truly RESTful way you would have to be able to 
communicate actions as well as data.

Unfortunately it doesn't look like anyone is seriously pursuing such an 
idea.

Frank