Anyone on the cutting edge of service orientation and cloud lives in a universe of application programming interfaces (APIs), which serve as the gateways to functionality across the Web as well as enterprise systems.
The perception and ideal is that APIs can be readily snapped into an architecture to complete a process, much as Lego blocks can be snapped together. That’s the ideal, mind you.
Matt Mullen provides a reality check with this kind of thinking, reminding us again that APIs do not offer themselves to quick assembly in the style of Lego blocks. The problem is, he says, no two APIs are alike:
“Not only are APIs certainly not like Lego, they are not equal. Talk to a developer and you’ll find out pretty quickly that they range from the well-formed and functional to the fiendishly complex and arcane. Then ask about the documentation. Then probably buy them a beer to recover from having to relive personal nightmares.”
The key to successfully working with APIs, Mullen continues, is to thoroughly understand the business process that will flow through the APIs. Then, be sure to get the documentation to share with your team, and be ready for the integration and customization work required to make the service work with your existing systems.
What should a well-designed API look like? For those on the design side of APIs, Layer 7’s Scott Morrison shares some resources in a new post. “APIs are a little like cockroaches in that they will likely outlive the human race,” he muses. Morrison points to recommendations from Martin Fowler and a YouTube video of Joshua Bloch’s Google TechTalk on How to Design A Good API & Why it Matters. (From 2007, but more timely than ever — Video embedded below.)
“You have one chance to get it right,” Bloch said, noting that once done and deployed, an entire enterprise may wire itself into the existing API. “A bad API can cause an unending stream of support phone calls because people cannot make the thing do what it ought to do.”
