REST, uniformity and semantics

This is a follow-up to a comment that I made in the last telcom. It 
represents my personal understanding of the relationship between 
REST/SOA etc.

It is possible to stratify the space of Web services along the 
following lines (going bottom-up):

Level 0: Transport SOA.

At this level we have notions of messages, transports, encodings (XML 
etc), package formats etc. etc. The key aspect of a SOA is that 
everything is defined in terms of the messages exchanged and not in 
terms of any particular processing of those messages.

What is particularly missing from this level is ANY commitment as to 
the processing/understanding implied by sending or receiving a message; 
all that you have is the text/DOM tree of the message itself. (You can 
add types with no loss of generality.)

Level 1: Open/Custom SOA

The extra interpretation/commitment incorporated by the notion of an 
Open or custom SOA is that it is possible for parties to describe -- 
using standard specs -- the processing/understanding entailed by 
sending or receiving a message. This may be in the form of an API-like 
model but does not have to be. Currently SOAP/WSDL go a long way to 
permitting this kind of SOA.

Level 2a: REST SOA

The extra interpretation added here is that we restrict our language to 
one that is appropriate for manipulating resources. This comes in two 
parts: a limited vocabulary (GET/PUT/POST/DELETE) and a particular 
interpretation of the `payload' of a message (in particular, the 
argument of a PUT and POST is the representation of a resource)

A Level 2a SOA has some attractions in that it captures the world of 
the Web pretty well; but requires some bending to deal with many (if 
not most) real-world interactions between legal entities: namely 
ACTION. This leads to:

Level 2b: ACTION SOA

(This is mythical, but demonstrates that there are many alternatives to 
REST)

The extra interpretation added in ACTION SOA is that we restrict our 
language to one that is appropriate for expressing actions between 
legal entities; here I suggest INFORM, REQUEST, PROMISE, DECLARE as a 
reasonable initial starting point. In addition, the `payload' of a 
message takes the form of a fact or an action.

The real point behind this message is that by taking this kind of 
stratified view of the different levels of Web services it is clearer 
(to me anyway) what the relationship between SOA, REST, Web services 
etc. etc. is.

I hope that this helps.

Frank

Received on Monday, 12 May 2003 15:58:05 UTC