We had a Web application that used Windows Azure Table Storage (Microsoft’s highly scalable “NoSQL” implementation), and I was asked to do a prototype client using the final bits for Microsoft’s Windows Phone 7 SDK. Microsoft’s claimed strategic benefit in “The Cloud” is the integration of tools and technologies, and I was more than ready to enjoy some time in a single IDE, with a single SDK to recall.

My initial steps were very encouraging. Windows Phone 7 programming is done using Silverlight. Silverlight apps generally use the Model-View-ViewModel architecture, in which the View (the actual user interface) uses data binding to communicate with the interface logic in the ViewModel. This decoupling has at least two major advantages: Since there is little, if any, logic in the View, the developer can create a basic “programmer’s UI,” and graphic designers can, in parallel, create a snazzy look. The second advantage is that since there are no actual pixels or screens in the ViewModel, it’s much easier to automate testing of the interface logic.

Because I had mocked the Model objects coming from Table Storage, I was able to rapidly iterate and concentrate on the challenges of the mobile app. (Cue the distant rumble of an approaching storm.) I spent my time making sure that the most risky aspects of development—the mobile interface logic—were going to work. Indeed they did, and I sent the client a cheerful and confident message. (Cue the first drops of rain beginning to fall.)

It was time to do what was supposed to be the easiest part of the project: Add a “Service Reference” to the Azure Web Service and replace my mocked Model with the real thing. This was supposed to be the easy part because Microsoft is “all in” to the cloud. Because Windows Communication Foundation embodies all the lessons learned from SOAP. Because Microsoft’s whole claim to strategic value is that it provides complete end-to-end technology.

Yet, as it turns out, Windows Phone 7 does not allow you to use WCF to connect to Azure Table Storage out of the box. You need to install “WCF RIA Services for Silverlight 4.” Except that Windows Phone 7 is implemented on Silverlight 3.5. At which point, you will take solace in the fact that Windows Azure Table Storage can support a REST-ful interface.

Representational State Transfer is the architecture of the Web. It uses HTTP for transport and status codes, and it has a small set of verbs with well-defined semantics. Everything about it is human-readable and easy enough to mock for testing purposes: requests and responses, document definitions, and status codes (well, they’re encoded as numbers, such as the 404 that even grandparents have become familiar with). It is explicitly designed to work well with intermediaries, which means that you can use a tool like Fiddler 2 to study and even modify conversations and be confident in the results you see.

The “downside” of REST for Web Services is that, if you want programmable objects, you have to write your own serialization/deserialization code—unless you’re using a dynamic language, in which case someone’s undoubtedly written parsers for XML and JSON. With C#’s increasingly dynamic semantics, it’s possible that there was a ready-made solution out on the Web, but XML serialization is easy enough to hand-code that I did not want to risk another “gotcha” by introducing another library into the mix.

Perhaps I’ve made the switch from a WCF to a REST-ful interface seem straightforward, and as far as the code itself goes, it was. But it took me more than a full day of chasing false leads and alternatives to come to the still-tentative conclusion that there was no WCF-based solution currently available. (At one point, I had 26 reference tabs open in my browser and a two-page mind map trying to capture the cross-references and false leads.) And feel free to imagine Wagnerian “Sturm und Drang” at the late discovery that the client needed to modify the Web Service. As is often the case, touching the server code (even for the benign tweaks needed) triggered some attention and change-control, which ended up introducing significant overhead. Instead of a simple proof-of-concept and easy win, the Windows Phone 7 development was suddenly political.

There are two arguments one hears against REST: One is that “REST can’t do” distributed transactions, or complex trust relationships, or some such. I don’t know that those arguments are never true, but personally, I have never encountered a real use case where REST was incapable.

The more common argument is that alternatives to REST are easier to use. Indeed, when you use “Add Service Reference…” in Visual Studio and point it at a WCF service, or point at a SOAP service using other tools, and everything works, it’s a nice moment. But when these alternatives fail, you get into a world of tooling incompatibilities and versioning and messages dominated by machine-generated metadata.

While I have previously advocated REST in general, its becoming the savior in a 100% Microsoft solution was, for me, a telling victory. I just wish I had RESTed a little earlier.

Larry O’Brien is a technology consultant, analyst and writer. Read his blog at www.knowing.net.