5 Predictions For APIs: A Consumption Perspective
By Mark Geene, CEO and Co-Founder, Cloud Elements
This year, the relationship between application program interface (API) publisher and consumer is going to shift, and central to this is the Citizen Integrator. Traditionally, API integration has been the domain of software developers and IT organizations — until now. Citizen Integrators will be the primary consumers of APIs, but they are not yet directly marketed to by publishers.
In 2016, with the rise of Citizen Integrators, we’ll see a strong transition toward self-service and pre-built integrations that provide application administrators and application users with the ability to connect SaaS apps together in order to share and synchronize data among the apps they use to run their departments.
- More API Integrations Will Be Done By Citizen Integrators
The term “Citizen Integrator” is likely still a new one to many: Citizen Integrators are the non-technical people who will consume and integrate APIs more often than IT teams and developers in 2016. Think of them as the average business users, the app admins or business operations people. It’s a matter of practicality: There are too few developers, so your average business users will be the ones to integrate APIs. Marketing teams, sales departments, administrative team members — these are the non-IT Citizen Integrators who understand their data and have specific use cases to ensure they don’t duplicate data and expect applications to work together.
Why is this significant? According to Gartner’s Market Guide for Citizen Integrator Tools, by 2017, in large organizations, at least 65 percent of new integration flows will be developed outside of IT departments. Gartner also estimates that by 2018, more than half the cost of implementing 90 percent of the new large systems will be spent on integration, and by the end of this year organizations will spend more money on integrations outside their IT departments.
Integration has become a leading use case driving the consumption of APIs and will likely surpass the typical application development use case of employing APIs to enhance an application's functionality. Pay attention: Packaging your API to be consumed in self-service, non-developer integration use cases will become the leading use case for your API.
- Providing Pre-Built External Integrations Will Become A Competitive Imperative For SaaS Companies And Application Providers
Based on the rise of Citizen Integrators, you’ll see SaaS companies and application providers assuming much more integration responsibility. Until recently, application buyers were expected to buy apps that did not have the pre-built connections and then wait for their own IT departments to purchase and implement expensive tools like ESBs or iPaaS platforms to make them work together. Or, their route was to hire system integrators (for no small fee) to make the disparate systems work together.
However, with the proliferation of SaaS applications and the expanding range of options available in each category, buyers are becoming more insistent that the applications they buy work out-of-the-box with the applications they already have in place — or they won’t buy the new app. This expectation from buyers has led application providers to focus on offering more pre-built integrations along with their apps.
This year, this will move from a “nice-to-have” to a top strategic imperative for application providers to compete and dominate in their markets. Companies that want to become or remain industry leaders will not only provide pre-built connectors, but they’ll also provide embedded integration tools such as data mapping and bulk data migration, even workflow and orchestration capabilities, from within their apps.
- APIs Will (Finally) Embrace Customization
Every leading SaaS application offers users the ability to easily create, update, and delete custom data fields and custom data objects. This flexibility has led to a vast majority of app users relying on custom data within their applications as they tailor the data they capture to their business needs. However, very few SaaS applications provide custom object management within their APIs. To support these new modes of consumption, it’s imperative that API publishers recognize the need for their APIs to embrace the discovery and CRUD management of custom objects.
Salesforce is a leader in this area, offering the ability to discover custom data fields and objects and their metadata as well as the ability to create, update, and delete custom objects programmatically through APIs. As integration use cases become the primary means of consuming APIs, more application providers will follow Salesforce’s example and enhance the support for custom fields and objects within their APIs.
- Event Management Through APIs Will Become More Than An Afterthought
The purpose of API integration use cases is to move and synchronize data between endpoints. Business Process Management is now occurring by assembling APIs into orchestrated workflows that synchronize and coordinate activities among multiple endpoints. To accomplish these synchronization and workflow use cases requires the programmatic consumption of create, update, and delete events from the endpoints through APIs.
Webhooks provide the most efficient means for publishing events from an endpoint, as they don’t require the consuming application or service to periodically poll the endpoint for changes. Polling increases traffic, often impacting limiters set up by endpoints by increasing activity. By subscribing to webhooks, your application is notified only when a change is made, thereby reducing traffic.
Before and in 2015, only a very small percentage of endpoints supported webhooks (less than 10 percent of the over 100 integrations my company has completed). Of those, even endpoints that support webhooks often only provide support for a limited set of resources. Based on my discussions with API publishers, we will see more sophisticated event management, and webhook support become a high priority roadmap improvement, versus an afterthought, as more publishers embrace the needs of the rapidly growing integration use cases.
- Machine-Readable API Docs Will Go Mainstream
The advent of Swagger 2.0 in 2015 was remarkable, as Swagger was reborn as an Open API Definition Format (OADF) after being put into an Open API Initiative (OAI). API evangelist Kin Lane noted this as something to watch in 2016: “We reached another significant milestone in the API space today: […] the Swagger specification is being moved in a Linux Foundation group called the Open API Initiative (OAI)…[I’m] happy to see it be reborn, within the community-driven group, as a community-driven open spec.”
This enables applications to ingest an API model (e.g., JSON Model Schema), and then integrate and maintain the APIs while minimizing coding. The ability to electronically discover API models and identify changes to these models will facilitate more reliable and easier to maintain consumption of APIs.
This is a critical evolution, as machine-readable API docs take the human error out of testing. This makes for a higher-quality, more secure API, and it’s fundamental to establishing best practices as we move toward automated testing. Swagger 2.0, and the revitalized RAML, take machine-readable documentation from thought to tangible tools.