Tag Archives: development

We have worked with many APIs here at Layer 7. And over time we’ve seen it all, ranging from the good to the bad. We even see the downright ugly. Now a good API is a beautiful thing; it encourages innovation, abstracts appropriately, and is designed with enough forethought that nobody needs to change it down the road. Resiliency is a good quality in an API. APIs are a little like cockroaches in that they will likely outlive the human race.

But what about the other ones? The ugly and bad ones? This is where developers could use some guidance.

Truth is, good API design isn’t really hard, but it’s not easy. One thing I point people to is Leonard Richardson’s Maturity Model for REST, which Martin Fowler explores in his blog. Now I’m not a REST purist by any means—truth is I’m as guilty of quick-and-dirty HTTP tunneling hacks as the next guy—but when you see the maturity phases laid out so succinctly, you can’t help but be inspired to move toward more “resourceful” thinking and maybe even learn to love HATEOS. Part of good API design is knowing what you should aspire to, and Richardson’s model is much more concise and accessible than Fielding’s thesis.

Another good source of advice is Joshua Bloch’s superb Google Tech Talk How to Design A Good API and Why it Matters. Bloch wrote what is arguably the most important book about Java ever written, and indeed his talk is about APIs using Java as the model. But don’t let that deter you; virtually everything Bloch discusses is as relevant to RESTful JSON-style APIs as it is to Java. Follow his advice, transpose it to you language of choice, and frame it with an understanding of where you want to land in the maturity model for REST, and you will end the day with great APIs.

Promotion is a problem faced by every API developer. Long nights of coding have given form to the stroke of genius you had six months ago in the cafe. You’ve just written the API that will serve as the front door into your application. But how do you document this so that your peers will use it—and hopefully make you rich in the process?

Java had Javadoc, an innovation that managed to strike a surprisingly effective balance between ease of use and systematization (three cheers for strong typing and static binding). Web services “solved” the interface definition problem with WSDL, a standard only its authors could love (and some of these won’t admit to participating in conception). To the registry crowd was left the task of devising clever ways to document a SOAP API around the torturous abstractions of WSDL so that humans could grok it as effectively as the machines. Few would argue that their solutions were, well, solutions.

RESTful APIs neither benefit nor suffer from formalized approach and automation. Every so often WADL pokes its head up, only to be knocked decisively back into its hole in a community game of Standards-Whac-A-Mole. REST is—and indeed, has always been—a style that resists any formalism that threatens its simplicity and accessibility. For this, above all, the community deserves praise.

But this does leave a hole around documentation. APIs tend to be described-by-wiki, which can be great or just awful, depending on a developer’s ability to write and discipline to update. Good ideas like ProgrammableWeb showcase both of these extremes; however, the site suffers in particular from out-of-date API descriptions which is too bad.

Outside of the eventual acceptance en masse of some kind of standardized wiki template for APIs (which I think is actually quite likely), we probably won’t see substantial change in API documentation soon. Minor changes, though, can still count for a lot, and it’s worth pointing these out.

Google, always an innovator to watch, create a lot of APIs. They recently published the Periodic Table of Google APIs, which as its name suggests is a clever way to visually categorize their API portfolio into groups like mobile, data, geo, etc. It’s a bit gimmicky, but it is also fun and actually inspired me to try some new Google APIs that I wasn’t aware of before.

So, isn’t it about time for more creative solutions around API documentation?