The API Economy is coming into its own and gaining momentum. Major players are placing big bets: VC Firm Accel Partners has long been sanguine about APIs; last November, Google acquired API-platform vendor Apigee. The API Directory at ProgrammableWeb lists over 17,000 APIs today. We’re even starting to see market consolidation: the Mashape and RapidAPI marketplaces are merging, yielding a single portal with over 7,500 APIs listed, and allowing Mashape to focus on its API-gateway products.

A new industry is taking shape around APIs. To understand the dynamic that is creating the API future, a bit of historical perspective is in order.

In the 1980s, businesses began connecting the computers within their walls via Local Area Networks. Shortly thereafter, the first Internet Service Providers allowed even small, less tech-savvy businesses to connect to one another, and eventually to the whole world via e-mail, the Web, and the Internet economy we know today.

What the combinations of LANs and the Internet did for computer-based communications, the combination of APIs and microservices will do for applications.

Thanks to APIs and microservices, what we now know as an “application” will cease to exist, or at least, become as absurd and uninteresting as a computer not connected to a network. Desired features (as containerized microservices) will be combined and reassembled (via APIs) ad hoc, on demand, for a specific purpose, with a lifespan dictated by that purpose.

Of course, this vision is beyond our reach today because of the diversity of methods, techniques and architectures used in API products. It is as if, in our enthusiasm to apply the powerful new tools, we have created something of an IT Tower of Babel. Sure, there are standards like REST and GraphQL for accessing APIs; and others like OpenAPISpec and RAML for defining them. Many best practices exist for basic API operations, such as the ubiquitous CRUD (Create / Read / Update / Delete), that keep API access somewhat consistent from one provider to the next. But beyond those basics, the ever-growing number of APIs is a massive global game of Anything Goes.

Diversity is usually a good thing. Developers are rightly suspicious of any encroaching Dictatorship of Standards that normalizes software architecture or behavior at the expense of creativity or flexibility. On the other hand, with each API using its own approach, the global API-developer community is pulling in many different directions. As a result, a great deal of energy — and value — is being lost. “Anything Goes” doesn’t scale.

How, then, do we solve this problem for the emerging API economy without bowing down to overly-restrictive standards, and without spending all our time retrofitting APIs to coexist in some semblance of harmony?

Easy. Be Boring.

APIs deliver the most value when they are boring — that is, when they don’t overreach in the features or services they provide to the API consumer.

Boring feature sets provide more value in two main ways:

  • First, by reducing complexity, thus making it easier to consume multiple APIs coherently in a single app, which is the goal when moving from monolithic software “applications” to containerized architectures; and
  • Second, by optimizing for the API consumer’s skills and strengths. If APIs can provide the boring features necessary to a developer’s app, but not part of its core value — things like “Save as PDF,” “Display the weather” or “Notify via email,” for example — the developer has more time to build core features and add core value… more time to make their app Sexy.

Thus, when it comes to API design, Boring is the New Sexy. At Hubrix, our mission is to execute Boring bits as well as possible, so our customers have more time to be Sexy.

Interested? Leave us a comment. Or better yet, share your views by completing our 2017 API Developer Survey


Share This