> protocols. And both make the point about tunnelling, which is a form of
> fraud. (by the way, I'm in favour of tunnelling in some
> circumstances...but I know it is an intrinsic blow against security).
Like when I create a PPTP tunnel over the Internet to dial in to my corporate account? Is that an intrinsic blow against security? Like when I use SOAP with XML encryption over HTTP? That also is a blow against security? When people start saying things like "tunneling is bad for security, unqualified" or "REST is better than RPC for security, unqualified", my religion-meter starts going berserk. "There is one REST and no other gods before him" is not a reasonable approach to architecture.
> So to say it "isn't RPC versus REST" is to miss the point. These two
> people who know ten times more than I do about protocols and security
> both claim it is *entirely about RPC*.
I will boil your long argument down to this: you claim that HTTP in a REST model is secure, because an admin can trust that a GET does not modify resources, and he can control access to other more "dangerous" verbs. You are upset because embedding SOAP in an HTTP GET (which is by no means a requirement) does not give any such guarantees.
Maybe SOAP is being realistic. HTTP GET betrayed this promise years ago -- GET *can* modify resources, and any admin who obliviously ignores this fact by adopting your "we can trust REST" attitude is making a serious error. Saying that "GET does not modify resources, POST might, and PUT will" is nice on paper, but seems to be far past the point of rescue as a practical reality. If you ask most IT people the difference between GET and POST, they will say "GET allows me to send form parameters on the querystring, so I can use URLs to post form data. POST allows me to send more information to the form, and is useful when I need to hide the information from prying eyes." I am not saying this is a desirable understanding, but it sure is how things turned out. Blame it on the guy who invented FORM METHOD=GET. Second, people already use form fields (both POST and GET) to directly feed parameters to Java and COM+ objects. This is not only pervasive, it is considered "best practice" by many shops.
So, is it good advice to tell people that their HTTP+Forms web apps are more secure than SOAP-based apps would be? I think in fact this is dangerously bad advice. Best to lose the religion and tell them that security is a discipline, and that they will ultimately need to assign ACLs to the operations that they expose. At least SOAP doesn't claim to omnipotently solve this problem.
