It's been qutie a few years since I first heard of "Web Services", I'm sure most of us have been using them a lot longer, they just had different names back then, (like screen scraping ;). I remember there being a big buzz about it though, SOAP was the latest and greatest and was going to change the way business and software works forever! Even my boss had heard about it and was getting all excited. There were going to be all kinds of services you could just plug into when you needed, you'd be able to book a flight from your diary, do a currency conversion in excel or even order a dvd with your tv remote. There was even going to be a big universal directory, where you could find a service and connect to it on the fly! All down to this new W3C standard. So what happened? Where are they? and if they're out there why aren't we using them? There has been a big growth in web services though, we've been calling it web 2.0. Flickr, del.icio.us, lastfm, ebay, amazon and lots more have powerful APIs that allow programmers to access most of the functionality of their systems. None of them use SOAP though, (flickr offer a SOAP interface but it's a loose wrapper that doesn't take advantage of any of SOAPs features). Most of these systems use simple XML/REST over HTTP (a few also offer JSON, APP and some others). Web services did happen. They've been kick started by these folksonomic web 2 startups that needed to open up their data to the people who created it for them in the first place. In doing so it's introduced this new culture of mashups that the old school web businesses are cottoning on to. Ebay and Amazon understand that by opening up their systems to programmers, they can have many more interfaces for consumers to spend than they could write on their own. I have to say as a .net developer, using a well designed SOAP service is so much more fun than a loosely typed REST API. We use SOAP in a few of our internal systems and when integrating with some of our partners. That is a controlled environment though, with clearly defined limits of load and implementation. On the web it's a bit different, you want your API to be easy for .net guys with Visual Studio, perl hackers on some free linux hosting or Mobile App developers using Java ME. I should probably stop whinging, there are great .net libraries for most of the common APIs and developing interesting web based applications has never been easier! The mashable web is here to stay, who cares about SOAP!

Labels: api, soap, web services, web2, xml

The key concept that feeds the mashup community is open data, all those nice APIs into flickr, del.icio.us, last.fm etc. They let us do fun things with photos and music listening habits, but the really useful data is always locked away. A good example is the Royal Mail address database, unlike america you need to pay a lot of money to do anything useful with that. But what about the data we own? all our personal data, locked away in systems that we can't do anything with. When I log on to my internet bank they won't even let me right click and view source! They do offer a download of my statement into a few archaic formats, like ofx (along with invalid xml!). I could do so much more with this data if I didn't have to keep manually logging in to and downloading files. I want a live feed of the state of my finances. I'm thinking of starting an open source project to develop a simple yet powerful api to internet banks that parses the data out of the banks own website and gives it back to you in a nice DataSet with all the info you could need. Then possibly this could be extended to allow making transactions between accounts or other things. Of course security would be an issue, the account login details would have to be stored in full on the machine using the API, or passed in from a client. I hope it's just a matter of time before banks catch on to this and start offering interfaces with things like read-only logons. Then again, I won't be holding my breath.

Labels: api, banking, finance, mashup