RE: REST wrap-up (was Re: Web Services Architecture Document

Yes, if you define just two verbs: SEND and RECEIVE, then it is RESTful.
Even better, if you make them the standard part of your SOAP, then all
systems can SEND and RECEIVE independent of underline protocals. 

The only question is: why re-invent the wheel?  We already have the Web,
which has already defined a small set of verbs.  Your SEND and RECEIVE are
just the same as POST and GET.

Hao

-----Original Message-----
From: Jim Webber [mailto:Jim.Webber@newcastle.ac.uk]
Sent: Monday, 9 February 2004 13:42
To: Mark Baker
Cc: www-ws-arch@w3.org
Subject: RE: REST wrap-up (was Re: Web Services Architecture Document



Hey Mark:

> A message is not an application abstraction, it's the means 
> by which an abstraction is utilized.  Using the canonical 
> stock quote example, the stock is the abstraction (the thing 
> with the interface), and the messages manipulate that 
> abstraction using that interface.

No, no, no. It is up to me what my abstractions are, and at the WSA
level I choose "message" (hey, this is like Pokemon!). That message
might convey stuff which is resolved by the application into something
more specific (e.g. a stock quote), but that is not important at this
level.

Maybe I can put it in REST-like terms (in fact Savas and I have just
been discussing this very topic): a Web Service has two operations -
SEND and RECEIVE, which involve the use of an abstraction that I call a
"SOAP message." This is like your generic REST interfaces, except this
interface is independent even of URI scheme and doesn't care what
transfer protocol you use.

All you care about is that messages are sent and received, therefore
mesasge is a valid abstraction. It might not be valid from your
perspective, but then it strikes me that not much that I work in
generally is :-)

Jim