You got your REST in my SOA

There’s a great article by Steve Vinoski in the Jan/Feb 2007 Internet Computing on the difference(s) between SOA and REST as architectural concepts and approaches titled “REST Eye for the SOA Guy.”
In the intro, he writes:

I’m torn in the Representational State Transfer (REST) and SOA debate — REST is extremely appealing, but my technical background is firmly rooted in the SOA camp. I’m torn in the Representational State Transfer (REST) and SOA debate — REST is extremely appealing, but my technical background is firmly rooted in the SOA camp.

In the end he comes out more on the side of “extremely appealing” than “firmly rooted.” Obviously there’s room for both, but REST comes off as much more attractive than SOA, at least in his version of the story.

For example, in the section on uniform interfaces, he clearly prefers the REST model of uniform interfaces: “there’s no question that the uniform interface constrain can allow for more highly scalable systems.” He goes on to note that “some of the architects and developers I know who work on large SOA systems . . . figured out the uniform interface constrain on their own, without ever hearing of REST.”

When it comes to data variability, he declares that “although data variability is indeed a factor in both SOA and REST systems, REST has an advantage here as well,” because “data formats are necessarily orthogonal to interfaces.” Because the interfaces are uniform, there is no coupling of interface contract to data format.

Finally, in terms of resource naming, “REST provides more guidance and consistency that SOA.” This section is the one in which the advantage is least clearly given to the REST camp, and it’s the only section that’s just one paragraph.

The conclusion makes the argument that “many SOA developers are far too quick to dismiss REST” and suggsts that “truly understanding REST can help you build more scalable and better performing distributed systems.”

He’s right – but perhaps he risks making SOA into WS-* just as he accuses SOA developers of seeing REST as “just HTTP.”