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

Received on Wednesday, 8 January 2003 13:12:48 UTC