Give and take
by William VambenepeI wasn’t looking for yet another “REST vs. Web Services” thread but Pete Lacey sucked me in (and many others) by hooking us with a hilarious bait post and since then he’s been pulling strongly on the line with very serious discussions on the topic so we haven’t been able to let go. The latest one left me a little puzzled though. In the security section Pete writes that it would make sense to use WS-Security indeed (and the SOAP envelope as a wrapper) if there was a need for message-level security rather than simply transport-level security. And then, barely catching his breath, he dismisses WS-Transfer and WS-Enumeration in the following paragraph on the basis that “these specifications effectively re-implement HTTP” (not really true for WS-Enumeration but let’s leave that aside). More importantly, how am I to reconcile this with the previous paragraph? Once I use WS-Security and the SOAP envelope, I can’t use pure HTTP anymore. But the patterns supported by HTTP are still very useful. That’s what WS-Transfer is for. That’s what SOAP is for more generally, providing a hook-up point for things like WS-Security that compose with the rest of the message. I don’t understand how Pete can concede that in some cases message-level security is useful but then take away the possibility to do a GET in these circumstances. Is he saying that for some reason the scenarios that justify message-level security are scenarios in which REST-style interactions don’t apply?
January 4th, 2007 at 5:10 pm
“Once I use WS-Security and the SOAP envelope, I can’t use pure HTTP anymore.”
Not true. The SOAP envelope is just that, an envelope. Not unlike the HTML envelope. It can be used with plain old HTTP just fine. I can GET a representation that looks like this (namespaces elided for brevity):
…
…
And PUT and POST that equally well. It’s just XML after all. If the elipses in the Header were replaced with WS-Security related elements, that would present no issues either. Again, it’s just XML.
Where SOAP goes off the rails is in ignoring HTTP and trying to be protocol/transport agnostic, then, when using HTTP, tunneling _everything_ through POST. But the part of the spec that defines an evelope, that’s fine.
January 4th, 2007 at 5:12 pm
Damn, you’re comment filter removed my XML. Just imagine those elipses being surrounded by Header and Body elements and those being surrounded by an Envelope element.
January 5th, 2007 at 1:56 am
Sorry about the comment filter Pete. I get your point, you meant this structure:
[envelope]
[header]
…
[/header]
[body]
…
[/body]
[/envelope]
And yes, this is of course XML so it can be passed around through HTTP GET, PUT, etc. But when you do it this way, you’re not encrypting the whole message since the verb is outside the envelope. Depending on the semantics of your application, it could very well be a serious information leak for someone to see that you’re doing a bunch of DELETE or PUT operations. Same problem with regards to signature. If you sent me such a message and sign it, I can prove that you sent me the payload but I can’t prove whether it was part of a PUT, a GET or a HEAD. If this is meaningful (and it should be, right?) then I need this information to be signed as well. Otherwise it’s like having a contract where the dollar value is signed, but the part that says whether it’s a gift or a loan is not. Which is why in these message-level security scenarios you need the verb/action information inside the part of the message that you sign.