APIs are coming into their own. Gluecon was abuzz with them. I've seen Sam Ramji's talk on Darwin's Finchs and APIs referenced everywhere--and rightly so.

One of the problems with RESTful APIs, however, is that every time someone comes up with an API, I have to read the docs and then code, by hand, an interface between that API and my language. For popular APIs libraries are already written to do that. For smaller APIs, I'm on my own.

At the Cloud Camp that preceded Gluecon, one of the discussions was about a way to fix that: an API description language (sometimes called an IDL). Using an IDL, interfaces to an API for any given language can be generated rather than written by hand. WSDL, of course, is such a language for SOAP but it's not suitable for REST. There have been attempts to create description languages for RESTful APIs (like WRDL) but they've failed to take off. Some would argue that REST doesn't need a description language, that it's too heavyweight, but I, for one, am tired of writing libraries to every API that I want to use--especially as the number of authorization protocols like OAuth and UMA propagate.

There's an alternative to IDLs, however, that's even better: declarative references. XRI + XDI are a system for creating declarative references to data. XRI provides a language for describing the data you want without specifically saying how to get it. When an XRI is dereferenced, it can point to an XDI data store that contains the data. How's this different than performing an HTTP GET on a URI?

• If the RESTful API is very well designed, it's largely the same with a few exceptions (which I outline below). Putting together an XRI reference for data is not necessarily easier than putting together the URI for someone's random data element. But most RESTful APIs aren't well designed; they force programmers to write lots of code to get around API inconsistencies. XRI/XDI has thought these issues through.
• Non-standard implementations of authorization standards like OAuth (are you listening Google) in RESTful APIs just add insult to injury. XDI has a single, comprehensive, portable authorization scheme called link contracts that normalize access to data.
• XRIs are location independent because they resolve to an XRDS document that is used to get to the right location. That means I can change the location of my data--even if I'm storing it on someone else's servers using their domain name--and things just keep right on ticking.
• Moreover, XDI creates an RDF-like scheme called the XDI graph which means that the data stored in an XDI store is portable from one XDI store to another.
• XDI includes the ability to interrogate and inspect the data dictionary associated with a store, providing a semantic namespace that is referencable through XRIs. This means that creating the reference is most standardized than just putting together a URL according to someone's whim.

All of this convinces me that as we move to a world where personal data is more and more important, we're going to need something more than what HTTP+URIs provide. That doesn't mean they'll go away. They'll continue to be a critical building block. But we'll move up the stack to something that plugs some of the holes in HTTP. I think XRI+XDI is a good candidate.