APIs are hot, so much so that some major firms are mandating that all future services must be delivered as RESTful APIs. Why? Most API enthusiasts trace the foundation of the API Economy movement back to Jeff Bezos’ somewhat infamous mandate in 2002 that all (developer) teams had to provide services (APIs) as the only means of exposing data and functions to other teams, and that these APIs must be designed from the start to be externalizable (consumable by teams outside Amazon).
Since then the number of APIs has exploded. Consider this data from ProgrammableWeb, an organization that registers publicly available APIs:
But as Mom said, just because the other kids are doing it doesn’t make it right – so why all the interest? Is it right for you?
Probably, as there are a growing number of reasons to embrace APIs:
- Firms can monetize their core capabilities by exposing them as APIs, generating new revenue. For example, credit-card processors were motivated to expose payment APIs when PayPal started taking market share on the web by offering one of the first large-scale payment APIs, and now credit-cards, banks, and other financial institutions are driving a lot of new business through APIs.
- Developers are attracted to good APIs, and they form communities around popular APIs. Firms like Amazon and Google build API platforms that make money by attracting developers who use those platforms to deliver apps and services (which also make money). Many companies have built their business on AWS, including household names such as Netflix, Spotify, Pinterest, Ubisoft, Etsy, Foursquare, Airbnb, IMDb, Flipboard, and many others.
- Developer communities build ecosystems that add value for customers, driving a virtuous circle that drives more revenue back to the core platform. This works as well for financial institutions as it does for Amazon and Google.
- Mobile app developers love APIs, too. Few things speed mobile development projects as much as a good API layer that exposes the back-end resources those apps need to do the stuff customers want, from exploring houses for sale or rent in a neighborhood, to ordering a pizza, to hailing a cab. Forrester analyst Michael Facemire puts it strongly, advising mobile developers to embrace APIs or dig their graves.
- APIs are the best way to leverage the Data Economy. APIs are data-centric by design, and a lot of what’s being monetized through APIs is access to data that has business value. Firms that make money off data used to have to deliver it on CDs or DVDs, or through proprietary APIs or terminals – now just about all new use cases want this data exposed via “open” APIs.
So if you have data or services that have value to others, are building mobile apps, or want to cultivate your own developer community or ecosystem, APIs are by far the best way to go about it. But how to get started? In my former life as a Forrester analyst, I gave this advice. What I’d add today:
- Your API design strategy must include service portfolio management and service design lifecycle management. How will you make sure that:
- You build the right APIs and avoid needless redundancy?
- Developers see and understand the APIs they should be using, as early as when the API is still a twinkle in its author’s eye?
- The services behind those APIs can evolve over time to support new requirements, without breaking existing apps?
- My earlier advice was to start by understanding your business context because I think it’s critical that you take a business-led approach to service design. It’s only from a perspective of understanding the overall business strategy that you can appreciate which APIs you should be building, with what priority.
- Follow a design-led, technology-independent approach to services and APIs. What if, a few years ago, you had built your whole services strategy hard-wired to SOAP (the Web Services alternative to REST)? Today you might have to discard much of that investment to embrace REST. Instead, use tools that define services abstracted from the underlying technology, so that when the “next big thing” comes along (after REST), you can rapidly pivot to embrace the new technology paradigm.
What is the “next big thing” after REST?
It will probably be just the natural evolution of what we now call “RESTful” approaches, on top of the evolving infrastructure of the Internet, taking into account the evolution of the Internet of things, real-time, Big Data, etc. That evolution could still cause you pain if it obsoletes APIs you’ve based on earlier models of how REST should be done. Given the number of opinions around today about what constitutes “good” practices for RESTful API design, that’s not hard to imagine… so prepare for the future: take a design-led approach to APIs with ignite!