RESTful Web APIs_2013
An API released today will be named after the company that hosts it. We talk about the “Twitter API,” the “Facebook API,” and the “Google+ API.” These three APIs do similar things. They all have some notion of user accounts and (among other things) they alllet users post a little bit of text to their accounts. But each API has a completely different design. Learning one API doesn't help you learn the next one.Of course, Twitter, Facebook, and Google are big companies that compete with each other. They don't want to make it easy for you to learn their competitors' APIs. But small companies and nonprofits do the same thing. They design their APIs as though nobody else had ever had a similar idea. This interferes with their goal of getting people to actually use their APIs.
Let me show you just one example. The website ProgrammableWeb http://www.programmableweb.com/ has a directory of over 8,000 APIs. As I write this, it knows about 57 microblogging APIs—APIs whose main purpose is posting a little bit of text to a user account. It's great that there are 57 companies publishing APIs in this field, but do we really need 57 different designs? We're not talking about something complicated here, like insurance policies or regulatory compliance. We're talking about posting a little bit of text to a user account. Do you want to be the one who designs the 58th microblogging API?The obvious solution would be to create a standard for microblogging APIs. But there already is a standard that would work just fine: the Atom Publishing Protocol. It was published in 2005, and almost nobody uses it. There's something about APIs that makes everyone want to design their own from scratch, even when that makes no sense from a business perspective.I don't think I can single-handledly stop this wasted effort, but I do think I can breakdown the problem into parts that make sense, and present some ways for a new API to reuse work that's already been done.