I’ve been reading a lot about REST, REST vs. SOAP, and security lately and came across this email thread post about how SOAP is so unsecure:
REST is not a security panacea. There is no silver bullet. All we can do is evaluate each layer’s *contribution* to security. SOAP’s is negative.It detracts from the security of the protocols that it runs on top of. If that were not the case then you would not be defensive about the idea that SOAP is designed to bypass firewalls.
I think I agree. SOAP does detract from the security of the protocols it runs on top of. Its trying to tunnel through port 80 and sneak past operations aversions to things like CORBA traffic. But is this such a bad thing? As far as this particular aspect of the SOAP vs. REST debate goes, what is the real underlying issue here? What I think it is is a matter of control. Ops doesn’t want CORBA/SOAP like requests because they can’t control what’s going back and forth over the wire. Control of the application has passed from operations to engineering.
From a developer point of view, we usually hate operations. You know the people I’m talking about. The control-freak paranoid dweebs that take at least a day to respond to any of our requests? They are the ones enforcing 10 character passwords that must be both alpha numeric, contain punctuation, upper and lower case, and that change once a month. They are the ones we have to sit in 3 hour meetings on whether to upgrade a certain library. It is like pulling teeth to get an operations guy to do anything beyond what they are trained to do. They are change resistant. They usually end up being blockers to our productivity. So its only natural that us developers would want to tunnel over HTTP to bypass these clowns. We have problems to solve, deadlines to meet, management breathing down our backs. They are the bureaucracy. Nobody is gonna come down on them when we can’t meet our deadlines.
On the flip side, operations is used to handling security issues. They have pre-existing tools and experience to deal with securing HTTP resources. Plus, managing the security aspect of an application is a tedious task. As developers, don’t we want ops handling this? Also, do we really want to waste the time training these idiots to a new technology? I guess it really depends how tech savvy and un-unionlike your ops guys are.
Side note:
Man, seems like I’m falling more and more into the REST camp. Its simpler. I want it to succeed. I’ve always disliked WS-*. But really, its probably because I’ve been focusing on pro-REST propaganda lately. I need to read some pro-SOAP articles.
Aug 22, 2007 @ 15:17:17
Howdy Bill
Here is a REST epiphany run into by another popular blogger:
http://pluralsight.com/blogs/tewald/archive/2007/04/26/46984.aspx
If you browse to the blogs main page: http://pluralsight.com/blogs/tewald
you can also read posts that appeared after the link I mentioned above expanding on the said epiphany.
That blogger used to be a DCOM/COM+ wizard back in those days.
Aug 22, 2007 @ 19:52:19
You might find http://webservices.xml.com/pub/a/ws/2001/04/04/soap.html interesting from a historical perspective. I remember being at the first OMG meeting when SOAP was introduced to the CORBA world and people were fairly frank about one of the main reasons it had been developed: to tunnel through firewalls. There were all the debates you’d expect at the time: how do you secure it? how do you make it transactional?
I like REST. But then I also like WS-*. BTW, it’s a few months old, but check out http://www.infoq.com/news/2007/07/wsrest if you didn’t see it at the time.
Aug 22, 2007 @ 20:28:14
Eric is shutting down your access right about now.
Aug 22, 2007 @ 21:20:37
Mark, yeah, i read a bunch of the historical (hysterical) stuff. Especially from Don Box. What I like about REST is that the fundamentals can be applied to a WS-* environment as well as REST.
Aug 23, 2007 @ 09:56:05
You’re right. From an architectural perspective WS-* can learn a lot from REST and people are doing that (and vice versa). There are a few approaches (such as Message State Transfer) that try to meld the approaches. WS-Context is one WS-* standard that also tries to bridge the divide.
I’m sure you’ve read it several times, for for anyone else interested, check out Jim Waldo’s paper. Not on REST or WS-*, but still a good read.