For businesses, APIs are clearly evolving from a nice-to-have to a must-have. Externalization of back-end functionality so that apps can interact with systems, not just people, has become critical.
As we move into 2012, several API trends are emerging.
Enterprise APIs becoming mainstream
I see a lot of discussion about Facebook, Twitter and other public APIs. However, the excitement of these public APIs hides the real revolution. Namely, enterprises of all sizes are API-enabling their back-end systems. This opens up the aperture of the use of back-end systems, not just through apps built by the enterprise, but also through apps built by partners and independent developers.
For example, several large telecom enterprises, like AT&T, are embracing APIs because, even with their abundant resources, they cannot match what the world outside the enterprise can do for them — build apps that, in the end, bring in more business. Today, I estimate that 10% of enterprises are doing APIs, and another 10% are considering it. In 2012, I predict that these percentages are more likely to be 30% and 80%, respectively, reflecting the pace at which APIs are going mainstream.
API-centric architectures will be different from portal-centric or SOA-centric architectures
Websites (portals) are for people integration. Service-orientated architectures (SOA) are for app-to-app integration. While both websites and SOA use back-end systems through “internal” APIs, the new API world focuses on integration with apps and developers, not with people (via portals) or processes (via SOA). There are three specific things that are different:
- Enterprises need to think outside-in as opposed to inside-out. In an outside-in model, one would start with easy consumption (read REST) of perhaps “chatty” APIs and then improve upon them. This is in contrast to thinking performance first and ease of use second.
- Enterprises have to be comfortable handling unpredictable demand and rapidly changing usage patterns as opposed to the more predictable patterns in the enterprise software environment.
- Enterprises will need to make websites and even some internal processes clients of the “new” API layer instead of having them continue to use back-end systems directly. In this way, APIs will become the de facto and default way of accessing the back-end systems. Also, increasingly, the API layer will be delivered through a cloud model to handle the more rapid and evolving provisioning requirements.
Data-centric APIs increasingly common
Siri and WolframAlpha are great examples of data-centric APIs. There is a huge market for data, and today it is mostly made available through custom feeds (for example, Dun & Bradstreet) or through a sea of xls/csv files on a website (for example, Data.gov). The former is a highly paid model, and the latter is free-for-all model. Clearly, a new model will — and already is — emerging in the middle. This is the model in which data is brokered by APIs and free and freemium models will co-exist. Expect to see more examples of enterprises for which data is the primary business and where using the data through apps is the new business model.
The first thing enterprises like this are doing is to API-enable their data. Now, RESTifying data is not easy, and there are as many schools of thought on how best to do it as there are data providers. However, I expect some combination of conventional and de facto standards, such as the Open Data Protocol (OData), to become increasingly common. I do not believe that the semantic web or the Resource Description Framework (RDF) model of data interchange is the answer. It goes against the grain of ease of use and adoption.
Many enterprises will implement APIs just to get analytics
A common theme in enterprise technologies is that a spend happens first in business automation and second in business optimization. The former enables bottom-line improvements; the latter enables top-line improvements. The API-adoption juggernaut is currently focused on business automation. However, as more and more traffic flows through the APIs, analytics on these APIs provides an increasingly better view of the performance of the enterprise, thereby benefiting IT and business optimizations. If this trend continues and if business optimization is the ultimate goal, a logical conclusion is that APIs become a means to the end for optimization. Therefore, all enterprises focused on business optimization must implement APIs so they have one “choke point” from which a lot of business optimization analytics can derive data.
APIs optimized for the mobile developer
Mobile devices in general need to receive less data in API responses and should not have to make repeated API calls to perform simple tasks. Inefficient APIs make things worse for the app developer and the API provider because problems are multiplied by mobile demand patterns (many small API requests) and concurrency (the sheer number of devices hitting the API at once). In 2012, many providers will realize they need to:
- Let developers filter the size and content of the API response before it’s returned to the app.
OAuth 2.0 as the default security model
Apps are the new intermediaries in the digital world, enabling buyers and sellers to meet in ways that make the most sense. In the context of APIs, the buyer is the end-user and the seller is the API provider. Good apps are the ones that can package the provider’s API in a great user experience that encourages the end user to participate. The growth of apps as intermediaries with valued services like Salesforce.com, Twitter, Facebook, eBay, and others requires a way for users to try the app for the first time without compromising their private data and privileges.
OAuth 2.0 makes it easy for end users to adopt new apps because they can test them out. If they don’t like or don’t trust an app, users can terminate the app’s access to their account. In 2012, this will be the default choice for securing APIs that enable end-users to interact through apps with their valued services.