As the API movement marches forward, it continues to grind against the enterprise and its legacy of Service Oriented Architecture (SOA), which increases the frequency at which people ask me, What is the difference between API and SOA? This is not a technical explanation of the differences, but a philosophical one that many will argue does not apply, but in my opinion is the dark matter around the technological and business approach of SOA, that makes API work.
Many say that a web API is just one component in an SOA toolbox. This is true. Using HTTP for an API is not that novel in itself. That is until it jumped out of the enterprise petri dish, got a little oxygen to grow, allowing the introduction of some new aspects that the industry and technology overlords of SOA would never have introduced on their own.
While reading the Nation Building in the Age of APIs, by Matt McLarty (@MattMcLartyBC) of Layer7 today, he reminded me that:
"Every paradigm shift in technology has been driven by both innovation—the new technology itself—and application—how that technology can be used. In other words, there is a machine side and a people side to every technology change. The technologists responsible for implementing these changes often bias towards their comfort zone—the machine side—and overlook the people side."
He is right. APIs moves us closer to the people side of the equation, outside the technologists comfort zone, but I would also add that it moves it outside the business and industry leaderships comfort zone, introducing more balance that has the potential to make online communities, platforms and ecosystem thrive. Matt continues to say:
"Ultimately, the success of a company’s API will depend on the creation of a diverse community for that API—end users, partners, developers, and more—as well as the adoption of a business model that allows the API to contribute to the company’s bottom line."
SOA does a damn fine job of looking after the platforms (business), the developers (technology), but doesn't always provide for the best interest of the user--aka human side of the equation. APIs have allowed for valuable resources to flow around traditional IT bottlenecks, outside the firewall and be put to use by those who are potentially closer to the human problem that is being solved.
API introduces newer pieces of the SOA puzzle, found within the OAuth security relationship, terms of use and privacy policies, self-service access, transparency, while also providing monetization strategies that encourage partner and developer innovation.
At first glance, it is easy to mistake API as just part of the SOA toolbox, but there are other nuances that bring SOA closer to the users, and solving the real problems they face, by developers who understand. In the end I don't really think it matters whether you call it SOA or API, just make sure you include the essential ingredients that have worked with "open" APIs, whether your API is public, private or evolving your partner relationships.
