interoperability and the REST
[en] Scribbles	rest, soap, internet, computer, c9, 2007-10-28

Now that the REST protocol is all the fad... Sure REST is easier. Easier to understand; easier to implement; and probably easier to interop, especially true across organizational borders.  What I'm thinking about that what we're loosing by dumping RESTs big contender, SOAP. I feel that comparing REST and SOAP head to head is not really fair to either.

REST is about exposing data via URLs so that all data becomes content or Resources, as it's called in REST. Sure that data doesn't have to be static, it can perfectly well respond to a database table. The normal way of interacting with REST systems, is by posting to some sort of form. In some way, using REST is somehow like elevating the art of screen-scraping to the interop protocol. And the amazing thing it works pretty well!

As always, some things get easier, but other things get harder. I've now done three rest based integrations. An amazing thing of REST is that the non-technical managers have no problem understanding how it all works, but the programmers they're having a hard time. The programmers, Win32 programmers, are used to get all their interop done for them. Via SOAP methods, or DCOM objects or something. They get hidden from the reality of the information, and presents them with one known interface for working with it all. So now you have a generation of programmers that use the Internet everyday, but do not know how to read in an XML file or call a URL from within their development environment.

Of course, one can argue that the problem is the quality of the programmers involved and I agree, up to a point. But on the other hand, it makes me think that REST is assuming a much more able programmer then is the reality of many of them that are out there. And if they automate it all, like it has been done with SOAP. Microsoft already announced that VS 2008 will come with extended REST support.

My guess is that REST will get at least quite a few of the same problems that SOAP currently has with interoperability. In the end, it's the programmers not knowing what message really get constructed... and the construction libraries not doing exactly as the other end expects. And since there's a lot less spec surrounding REST then their is around SOAP... well... there's a lot more room for one big company to break REST in such a way that it works with nobody else.

We'll see how well REST survives mass market adaptation by mediocre programmers working with this-is-the-only-tool software.