When to put the web into Web Services

Adam Bosworth is trying to get his head around REST architecture and why it's useful. I certainly like REST, though I'm anything but fanatical about it. I have had good success with it in Syncato and I do believe that for what Syncato does REST was absolutely the right way to go. However, I'm still trying to wrap my head around exactly how applicable REST is to more complex Web Services interactions. I can certainly see value in the concepts behind what SOAP is doing, even if I don't particularly care for the actual implementation. The idea of an envelope that encapsulates the transaction is compelling on a number of levels, however hiding the data from the traditional URI space is a big turn off to me and I think the usage of W3C XML schema was a massive mistake.

Anyway, while I'm not yet convinced that everything about SOAP is bad, I do know when I see something that uses SOAP that would be far better off without it. I came across a perfect example of this yesterday. I'm not a big sports fan, but I do follow basketball and had been thinking about launching a new site about the local basketball team (who will remain nameless since they were the victim who ended the Magic's 19 game losing streak tonight). While looking around to see if anyone was already doing this, I came across a site for NBA blogs. As part of the site, they offer a web service to get the current NBA standings of all teams. Since this is a .Net site, the web service uses SOAP.

My first thought was wow, an actually useful SOAP service. However, looking at it more, I realized that this thing being a SOAP web service is about the worst way it could have been implemented. All it does is take one parameter that specifies the conference and then returns XML that lists the teams and their records. Wouldn't it be better to just put a couple XML files there? So instead of having to make a SOAP request to http://nbaweblog.com/nba/Standings.asmx you could just get http://nbaweblog.com/nba/StandingsEast.xml or http://nbaweblog.com/nba/StandingsWest.xml or better just get http://nbaweblog.com/nba/Standings.xml and then pick out the conference you want. This is where REST is so important, if you build your app against that SOAP service you're coupled to that service. However, if this is just an XML file at a URL:

• you can easily cache the file locally
• it can be cached at intermediate points around the network
• you can view it in a browser
• you can email it to your buddy
• people can mirror it in multiple places
• you can trivially turn it into HTML for presentation
• it's a lot easier to switch to an alternate source for the file or even recreate it your self.

So what are the benefits of this being a SOAP service? As far as I can tell, nothing. Not a single thing and you lose so much. Oh yeah, on top of everything that you lose, doing SOAP means that each time the file is retrieved it's a dynamic request. So it's even more costly for the provider.

Obviously, this is a highly simple case, but I really wonder, are the more complex cases really that much more complex? Or do we just make them that way due to misplaced emphasis on unsuitable technologies? Personally I'm still waiting to see a truly compelling usage of SOAP on the internet. So far every one I've seen would have really been better off just being built on REST principles. So, does a good example exist?

To me, the question isn't what's the value of REST, the question is what's the value of SOAP? I think this goes back to the idea of data-oriented programming, if you think in data oriented terms REST probably makes sense, but if you think in terms of programming languages then SOAP probably makes more sense. What's the better approach? Well, programming languages and computers are just tools for manipulating data right?

Posted by Kimbro Staken