REST Over HTTP

Harry Pierson asks a direct question about whether REST is necessarily bound to HTTP. I agree with Harry (and Anne Thomas-Manes as described here) that REST is an architectural style as much than anything else. And I also noticed this from the Alex James, who has a (self-described) rant on the subject. As much as the point is totally arguable and understandable, I think it’s an unwinnable battle.

I was at a WS-I meeting (the most productive one ever, BTW, because it was held here in Hawaii) a couple of years ago and casually asked Mark Nottingham (probably over a Monkey’s Lunch) about loosening the Basic Profile to allow for SOAP over TCP/IP. His answer was simply, “Why?” His point was this: Sure, you can drive SOAP over TCP/IP, Netware, whatever. But is there an interoperability goal in doing so? The answer is not really. You would need to own both sides of the pipe to make it work.

The IT industry is cozy with ports 80 and 8080. Opening up anything else practically requires an SEC 10-K disclosure. Come to think of it, we used to actually say “SOAP over HTTP” like they were independent and someone might actually use SOAP over SMTP.

I see the term “REST” in a similar situation. It’s tied to HTTP and it is probably impossible to wrest it away. I don’t have a problem with that – I’ll just learn to speak architecturally about “resource-orientation” and then about how to tie in “REST” out on the edge.