A great one from Jim this morning, about how REST seems to be all the buzz in various distributed computing communities. I noticed that too; it’s very cool, and a long time coming.
As for the cons, this one sentence of his seems to sum it up;
Sure REST’s message-oriented approach is sensible, but it has the downside of mixing the semantics of the SOAP message with those of the transport protocol.
What can I say? As I see it, that’s been the “Big Disconnect” since the whole Web services thing got started. Far too many people – especially those weened on CORBA, DCOM, and similarly styled architectures – just don’t appreciate the HUGELY important role played by application protocols. This is evident by the continual de-emphasis of them by treating them as transport protocols, as Jim does there, intentionally or not.
Document oriented SOAP messages should have no semantics by themselves, not even processMessage (modulo TCP – see below). The semantics should be provided by the underlying application protocol. That way, the semantics of a SOAP envelope being transferred with HTTP PUT won’t be confused with one being transferred with HTTP POST or SMTP DATA; they mean different things, and you can lookup those meanings in the HTTP and SMTP specs.
Now, if you sent it over TCP and want POST/DATA/processMessage-like semantics, you need to bind those semantics to the TCP port via an IANA registry.
Transport protocol (e.g. TCP, UDP) independence is good. Application protocol independence must die die die!
no comment until now