Many years ago, when I just learned about XML web services (it was around the time of the .NET 1.0 betas), one of the coolest things about it, I thought, was WSDL. The Web Service Description Language -- this is a language in which you essentially define the interface of a SOAP webservice. Not because it's a cool XML format (XML formats are hardly ever cool), but because it would allow to generate client proxies automatically from this description. So you'd find some XML webservice online, feed its WDSL interface description to some program and what you'd end up with is some C# class that allowed you to call the remote SOAP methods exposed on the web service, as method calls on a local object. Since then, generators that would do this have been developed for mostly every programming language. XML Webservices were going to conquer the world.
But not really. SOAP was considered too complex, too un-web-like. Too enterprisey. Too icky. Too, well, let's just say it, Microsofty. REST was the hot new thing. And it has been ever since. Google used to offer a SOAP interface, as well as JSON and other interfaces, but recently it stopped supporting SOAP. REST has become one of the main ingredients of every web 2.0 application. Yay for the web. Yay for simplicity. Yay for, diversification?
For a while now I've been wondering about why SOAP didn't make it. And especially if XML-RPC wouldn't be a good replacement for RPC (Remote Procedure Call). REST is mostly about manipulating resources (represented as URIs). You create them (POST), you write new content to them (PUT), you retrieve their content (GET) and you delete them (DELETE). Not everything can be represented like this, sometimes you just want to execute some method. Like in any program, objects don't only have properties, they have methods too. XML-RPC is very simple, is not coming from Microsoft and is pretty well supported. Why weren't we using that? Why all the awkward encoding of things in semi-REST calls?
But that's just how it is.
Back to a remark I made earlier, diversification. What I refer to here is that the format of results and data you send to a REST webservice is not more precisely defined than "dude, it's XML!" It's different for every service. Compare the flickr API to the Twitter API. If you were writing software that uses either of those services, there's not much of the code you can reuse. Sure you have your XML and HTTP libraries, but that's about it. Sure, it's not difficult to implement, but still it's engineering work. And quite some engineering work. And in case you didn't realize, it involves reading and writing XML files. Need I say more?
Now look back at XML web services. Remember about WSDL, where you can simply generate this interfacing code to the web services? That was pretty nifty. That saved a lot of work. Can't we do the same with RESTful web services? Well, yes, you can. And yes, finally I'm coming to my point.
You can do this with WADL. WADL stands for Web Application Description Language. It allows you to describe essentially any HTTP-based API to any web service Including SOAP webservices, if you would feel so inclined. But you can also describe the flickr API, the twitter API and the yahoo API in WADL. And guess what it can do...
It can generate client-side proxy code to interface with these Web APIs. Yes, it's like WSDL, but more general. Generalized to also support REST and basically any kind of (I guess) XML-based web service.
The main implementation is in Java, but apparently there are also generators for PHP, Ruby and Python. If WADL descriptions would be available to every awesome 2.0 web app available, people would spend a whole lot less time on writing libraries like this, this, this and this.