This was originally part of a post on the Yahoo! SOA mailing list.
I'm firmly a proponent of RESTful architectures (independent of whether they're over HTTP, or SOAP, or whatever underlying transfer protocol), as I believe they objectively lead to more scalable, interoperable and evolvable information systems.
Of course, nothing's perfect, and the implementations & tooling out there doesn't live up to the theory.
So when are alternatives appropriate? Stefan Tilkov suggests three simple factors:
I think #1 tends to be somewhat theoretical. I've seen lots of MQ out there, but not a lot of SOAP over MQ, for example. Such an approach is not overly interoperable, though I can see benefits of reusing WS-* infrastructure with proprietary infrastructure when within the bounds of a single vendor's stack, like IBM.
#2 true, but the implicit problem is that the term "enterprise" is sort of like "scalability"... it's often a way to shut down debate without studying the specific concerns. Debates on "Reliability", "Security", and "Transactions" for example, tend to require specialist knowledge and, lacking that, seem to hold a mystical status that cloudens debate when RESTful approaches may have very different views on these topics (even if they are well-founded).
I have a longer discussion & historical perspective on #3, which will be in a subsequent entry.
In the meantime, here's my (incomplete) list of scenarios of when you'd want an alternative to a RESTful protocol....
I think this is the approach that many vendors & enterprise architects are thinking will be the ultimately desirable scenario for WS-*. I'm curious how this will pan out, as I don't see a lot of discussion about the tradeoffs of this approach. It likely will succeed to a reasonable degree, though I don't think it actually helps a lot of the SOA desires for agility. Perhaps this is the area where the WS/REST bridges need to be built.
I don't really include security as a benefit of other approaches. RESTful web services can already reuse XML Signatures, XML Encryption, S/MIME, SSL, and allows for username/password, OpenID, Kerberos/SPNEGO, and SAML assertions already. WS-Security is just a wrapper for most of these approaches. Authorization rule engines tend to also be independent of whether something is RESTful (whether they're XACML, or proprietary, etc.) Though, a RESTful multi-party secure conversation protocol might be an interesting development in the future.
update: Just a quick clarification, as Stefan notes, that the three points he made were somewhat taken out of context from the SOA mailing list. He doesn't necessarily believe them to be true, just that they are common viewpoints.
Posted by stu at June 10, 2007 03:02 PM