The interactions between humans and machines creates a new set of relationships that we are just beginning to understand. We are becoming more machine-like, which changes the way we co-exist with each other. Data, once impeded, now flows in countless ways between people, machines and the infinite abstractions that force us to re-examine everything in our lives. For example, our phones can open doors and give us directions. Roads and bridges are as much nodes for transmitting data as a server cluster.
And the connector is the API, which increasingly serves as the communication between machines, people and things. These APIs have spread like paths across an infinite online landscape, transmitting data between apps and in the process creating new ways to live and work. And now APIs are connecting our bodies into systems that store and analyze our data for us to help better monitor the way we manage our own bodies.
What this all boils down to is the relationship between APIs. Here’s why. APIs are not smart. They are dumb connectors. But what we see emerging is a deeper context about APIs. Software is abstracting the infrastructure and the APIs are consuming the data that the software serves.
The startups that succeed will treat their APIs like crown jewels. Their APIs will always work, their documentation will be kept updated and they will have people to support it.
Unfortunately, that’s not really happening right now, and it’s hurting startups that actually have a great service to offer.
“It is the Wild, Wild West out there,” said Alex Salazar, co-founder of Stormpath, which provides authentication and user management for developers. Salazar said at AWS re:Invent that uptime is an issue but having someone available to answer a question is just as much a challenge.
PagerDuty is a service that offers IT monitoring tools through alerts via SMS, phone, email, iOS or Android. To make sure their service works properly, Founder Alex Solomon said they use three services for voice and six for SMS. “We have to deliver the alert every time,” Solomon said. “Our obsession is with reliability.”
So far, a small number of organizations have come to really understand the relationships between APIs. Amazon.com and Amazon Web Services, Google, Twitter, Twilio, Netflix, Dropbox and a handful of others have developed world-class services that are dependent on APIs for their success.
These companies have two things going for them. Developers want to build on the services they provide and the APIs are entirely reliable.
In Google’s case, the company has built its own internal API infrastructure. It provides a consistency in API design, authentication, connectivity, management and billing. Google’s constant challenge is to manage its APis at scale. That requires an infrastructure that can adapt and provide the granularity that developers demand. The other part stems from how Google works with its partners and the end customer. The API has to be easy to use for the partners that are consuming them. Google looks to the ecosystem for how to serve the end-customer who may be a data analyst who needs a visual interface or a developer who wants to work from the command line. The challenge is working with these developers so they can provide that secret sauce to that end user.
Google has a depth in its APIs that reflects an “implied contract,” that a new generation of APIs provide, said Tidemark Founder and CEO Christian Gheorghe in a Twitter exchange.
@alexwilliams good APIs are implied contracts – exposing at the very least a closer understanding of form and function ready to be consumed
— Christian Gheorghe (@optian) December 1, 2013
For example, with Google Maps, users will give a starting and end point for a trip and then the service provides the best route. The API is the connector but the services that feed it are the value to the developer.
The cornerstone of this new generation of providers comes from the ability to abstract data and connect APIs through everything from mobile apps to wearable devices. Their success will depend on how well they manage the services they both consume and provide.
Firebase, for example, offers a real-time service for managing apps that orchestrates back-end tasks. All the complexities are managed on the back-end and served to the app through the Firebase data storage API.
Big data app provider Wibidata, for example, has developed a framework for companies to develop services that stores the user’s data across multiple dimensions. A more traditional provider requires deeper, often custom integrations to integrate different data sources.
An important consideration for an API provider should be identity and data heterogeneity, said John Sheehan, CEO and Co-Founder at Runscope, which offers a service for monitoring API traffic.
A person/user will typically have several representations across different services. For instance, we have an internal customer record with a unique ID. When we work with our payment provider they have a different unique ID that identifies them on that system. We have to maintain that relationship on both sides by storing the other service’s unique ID. The more services you have, the more associations you have to keep track of.
Sheehan said there will likely never be one true data model and that is compounded by the prevalence of SDKs and API client libraries that represent data from the provider’s viewpoint instead of the app’s viewpoint. Writing translation layers can be time-consuming and brittle. This is one big reason Sheehan says that he always recommends skipping an SDK and making direct API calls whenever possible. A thin, app-specific abstraction layer over direct calls is much easier to maintain over the long term.
A new generation of wearables will make it even more complex to orchestrate data and manage the relationship between APIs. José Parrella, an open-source strategy manager at Microsoft, wrote in a blog post last month that it is arguable within a couple of years we will have small, fashionable devices that people can attach to the sides of their heads that they use to monitor electrocardiogram signals.
But one important part of wearables is the interaction among wearables: an API for your self. Provided you are willing, your wearables can share and request data from others, like your current mood, cultural and personality traits, preferences for this day (food, activities, agenda) and present it to the user in an assertive way to improve relationships, productivity and effectiveness.
In the API-driven economy, It’s not about creating “smart” or “big data” apps. It’s more about what the services offer. Pure API offerings are easy to build. But to offer context and reliability is a combination that can give any startup a chance of becoming something customers truly value.
(Image courtesy of NASA Goddard Space Flight Center on Flickr via Creative Commons)