Luke Razzell points to an article by Dion Hinchcliffe on REST vs. SOAP. Of course, everyone loves to compare SOAP and REST, but the comparison is usually based on what is best (read:easiest) for the developer. This is certainly a concern, but it is far from the only one. The article on REST's security model:
The actual XML message is contained in the HTTP request and security is provided by HTTPS, which is the secure version of HTTP. This, in a nutshell, is virtually everything that a Web service user or creator needs to know about REST.
SSL? Ok, deep breath. How can you say this Web 2.0 when your security model is not even sufficient for Web 1.0? Of course, there are ways of writing more secure code in a REST-ful way but they depend heavily on the correctness of the developer's implementation, and since we have 10+ years of evidence as to developer's "ability" to write secure web apps, this should cause concern. So when you need to deal with a REST vs. SOAP question, one of the things to analyze is how is REST going to deal with what WS-Security, WS-Trust, and SAML already do in a WS-* architecture, like encrypt and sign messages, and suppot multiple token types.
When it comes to security, SOAP v. REST is not a zero sum game. Security support can be:
a) in the framework (declarative)
b) in the code (programmatic)
c) both of the above
d) none of the above
Simply ruling out choice a for developer convenience is not a fair tradeoff.
Comments