So I’ve been working for the last few days using SharePoint’s web services extensively. They are pretty neat insofar as they offer a very public set of interfaces – the communication is pretty much human readable (for a given geekiness of human).

However, a couple of things have struck me. First was the bandwidth needed. Some of the calls I’m making were getting back 50k responses – and for a simple action in the app I’m working on, I could have to make lots of those just to display a form to a user. 1Mb downloads to show this form were likely – so this isn’t great. Presumably, enabling compression on the web server should reduce this considerably (looking at the XML in the file, it seems to have a high redundancy), but only at the cost of extra processing. Still, I can live with that.

The second, and in some ways more fundamental point, is that I find myself having to write wrappers for the various web services. I know, calling a web service in C# is dead easy, and that’s great, but the response -yuck! Everything seems to come back as lots of XML. And I do mean lots. I don’t actually want to deal with reams and reams of XML. Object oriented programming sort of implies that I should be trying to deal with objects. After all, that seems to be what much of ADO.NET is about – presenting data as objects.

So, for comparitively well known web services, can’t we have a pre-built wrapper so that I’m just dealing with objects? Both in and out. That way, well, if I want to talk to the web service via XML, directly, well, I can. If I’d sooner work with objects, then I could do that also. Just at the moment, there seems to be an asymmetry – I supply an function with parameters and it produces the request in XML. Then when I get the response, well, it’s just XML.

Hell, isn’t that what SOAP is all about? A common communication layer between remote objects?

In fact, thinking about it, some of the web service requests need XML put into them too – but that’s CAML, and another gripe entirely.