I’ve just been having a read about Facebook’s new FQL (i.e. Facebook Query Language) - basically it is a way to get data out of Facebook using a language very similar to the SQL we all know and love (?), returning the data in XML as you’d expect.
It is a little bit limited compared to standard SQL, for example you dont seem to be able to do joins and you can only use select on one table at a time, but even so what really struck me about this was the damn simplicity of it all. At the moment it seems that all the APIs I’ve had a look at are based on your usual imperative SOAP or XML-RPC calls. They are usually fairly rigid and you might need to do one or two (or three or four…) calls to get all of the data you need, then you’d chop and change that data in your code to get what you really wanted in the first place.
By offering a declarative interface to their data, Facebook have really simplified the entire process. Now just imagine how much easier it would be do throw together a mash-up if all the major API vendors offered a fairly standard declarative interface to their data - no more working your way through the endless documents, just a database schema and your standard SQL calls to the data and you’d be off!
A new mash-up middleware?
This got me thinking - people like eBay, Amazon, Google, Yahoo and many others already offer the usual interfaces to their APIs, but could there be scope for a 3rd party to act as the SQL go-between here? For example, a service that knows how to talk to each of those APIs, and offers up a single unified SQL interface for the developer to access to lot from one place?
It would certainly be quite a tough challenge to put that service together and get a reasonable level of performance out of it without charging, but its certainly something would might be able to be done as some sort of middleware to be used by mash-up developers…