Re: Hypermedia vs. data (long)

bhaugen wrote,
> I think both of those examples can be implemented using either
> message-oriented SOAP or REST or a transaction processor or probably
> other ways.
>
> So I think the business semantic argument can be taken off the table. 
> Not that either SOAP or REST solves them, but that it's orthogonal.

I'm in complete agreement with this.

Actually, I'd go a little further and say that the differences between 
SOAP and REST <emph>at the level at which they're specified</emph> are 
largely uninteresting. I can't get very excited by the choice between 
encoding semantically laden tokens in Request URIs vs. HTTP headers vs. 
HTTP entities ... viewed through a packet sniffer it's all just DNS and 
structured payloads getting shunted around.

> If that's true, then what are the advantages and disadvantages of each
> implementation? Or what are the situations where one or the other
> would be more suitable? (Which might be a more productive
> discussion...)

There are differences, maybe important ones, of attitude and approach. 
But those only really matter insofar as they shape the way you try and 
go beyond raw-SOAP or raw-REST and try and implement those orthogonal 
business semantics.

SOAP + WSDL or DAML-S would be one way to go. REST + X might be another 
if someone took the effort to fill in the 'X'. But that, unfortunately, 
seems to be something that REST fans haven't been particularly willing 
to explore ... other than a few vague gestures in the direction of 
"resource modelling".

I think that's a bit of a shame, because there are some interesting 
ideas lurking in REST and it's idioms which it might be possible to 
work up into something expressive enough to do some very interesting 
things with ... if my characterization of REST earlier is right, then 
there are surprising (to me at least) echoes of Milners Pi-calculus 
(eg. think of RESTs POST-a-URI and URI-in-a-Response idioms as 
analogous to mobility in Pi[1]).

Whether or not that particular idea makes any sense in the end, if the 
REST community don't come up with an 'X' which is at least as concrete 
and practically useful as WSDL or DAML-S they'll have only themselves 
to blame if RESTless SOAP wins by default.

[1] The diagram on p.3 of http://www.docs.uu.se/~joachim/intro.ps and
    surrounding explanation makes this analogy fairly vivid.

Cheers,


Miles

Received on Wednesday, 1 January 2003 14:27:58 UTC