Headlines That Condemn APIs Are Written For Clicks. Not Reality.

Go ahead and click on them. But take the headlines and much of the so-called substance behind them with a grain of salt. Within a couple of days of each other, TechCrunch and Intellyx have published a couple of rants that, in my opinion, do a great disservice to the API-curious and anybody else who reads them. If we were to believe these stories, we would be misled into thinking that the hype behind networkable APIs is largely unfounded and relegated to businesses of just a few types.

Over on TechCrunch, under the headline The API for Absurdity, RingCentral's vice president of Platform David Lee writes "One bit of API enthusiast rhetoric that concerns me is the 'composable enterprise,' a do-it-yourself approach to piecing together entire enterprise solutions." Lee goes on to say "Companies that have built successful businesses around the sale of discrete API services that can be plugged into larger applications would like to see this trend carried to an implausible extreme, where enterprises will move from buying software solutions to assembling their own business applications out of myriad APIs and microservices. The payoff is said to come in the form of ultimate, infinite customization." Arguing that most tech buyers' need "is for APIs that let them plug holes and fill gaps without having to work too hard" and that "they are looking for the simplest path to getting the results they want," Lee says "Let's get real, that [customization] is not going to happen."

Then, Intellyx president Jason Bloomberg penned his own rant against APIs under the similarly comdemning headline The API Lie. In that post, Bloomberg writes "Welcome to the API Economy! Now that we’ve worked all the kinks out of RESTful APIs, we now have seamless interoperability among all manner of endpoints, from legacy enterprise web services to microservices....If only it were that easy.....the elephant in the Integration room remains: data integration."  Bloomberg goes on to hold Web APIs themselves accountable for the sin of not fulfilling their promise of cloud-friendly integration and identifies SnapLogic as the white knight that can rescue you from the trough of RESTful disillusionment. He later discloses that SnapLogic is an Intellyx client. 

Man, it was as if I woke up on Monday morning and someone stuck a "Kick Me" sign on the back of the API economy. 

So, let's burn the "Kick Me" sign and set the record straight before some newcomers to APIs get so frightened that they run the other way.

One of Bloomberg's whipping boys -- REST -- is one of several architectural styles for how software components communicate. In my opinion, the most unique and beneficial "contribution" of REST has to do with the nearly ubiquitous understanding that software components now have for shuttling data and instructions between one another. By standardizing on a protocol like HTTP (and the set of commands baked into it; verbs like GET, PUT, POST, and DELETE), the days of bespoke connectors to get software components talking are waning. It's as though the software community got together and standardized on a commonly understood bus much the same way the PC hardware industry did the same with ISA. The burden on integrators and developers to get components talking to one another is greatly reduced because of a lingua franca that is universally understood. My software component doesn't need one set of commands to hookup with component-1 from across a network and a different set of commands to hookup with component-2. 

In his rant, Bloomberg writes "in the REST world, data integration is largely roll your own. At least in the Web services days we had XML schemas to keep us honest. Today, schemalessness is the way to go – providing the lightweight flexibility of JSON, but kicking the data integration can down the road."

The act of transforming that data (also mentioned by Bloomberg as a quality lacked by REST) or integrating it into a business process (also implied) was never a promise of REST and the ideas that schemas, XML or otherwise, "kept us honest" or that JSON's lightweight flexibility is somehow an inhibitor to integration is ridiculous. Bloomberg says "After all, REST is Web-centric: it provides for Internet media types (formerly known as MIME types) that can include metadata representations of data formats – but leaves the rest to you."  When criticizing REST, both HTTP (the "Web-centric part) and JSON are often guilty by association. Although actual RESTful APIs are most commonly found relying on the Web's protocol (HTTP), there are other protocols like CoAP (for the Internet of Things) that are also RESTful, but uninvolved with HTTP. LIkewise, ProgrammableWeb's API directory includes hundreds if not thousands of RESTful APIs that support XML-serialized data. 

And don't get me started about schemas. A decade ago, JSON-enabled APIs might have been schemaless. But today, such schemalessness is a choice by the API provider and not a problem that you automatically inherit because of your choice to embrace REST. The two pre-dominant API description specifictions -- Swagger and RAML -- both support JSON Schema, the tooling for which can be extremely powerful when designing APIs, enforcing data types, setting standards across an organization through schema reusability, validating requests and responses, and automating testing. Here, for example, is a JSON Schema-based schema for a coffee-related API that I'm kicking around for a forthcoming tutorial:

  "type"     :"object",
  "$schema"  : "http://json-schema.org/draft-04/schema",
  "id"       : "http://jsonschema.net",
  "required" : ["drinkName","drinkFamily","drinkBlurb","drinkHotCold","drinkWikiURL"],
  "properties": {
    "drinkName"   : {
      "type": "string",
      "minlength" : 3
    "drinkFamily" : {
      "enum": ["Black Espresso", "Milked Espresso"]
    "drinkBlurb"  : {
      "type":  "string",
      "minLength" : 20
    "drinkHotCold": {
      "enum": ["Hot", "Cold"]
    "drinkWikiURL": {
      "type": "string",
      "format": "uri"

It's not terribly fancy. But do you see the data types, formats, and other validation rules? It's powerful, machine-readable stuff, the potential of which is available to API providers who choose to take the time and reap the benefits of schemas for their APIs. Two cool attributes of JSON shemas is how they can broken down into re-usuable sub-schemas that can be "centrally" stored and referenced anywhere (the local filesystem, the corporate network, the Web, etc). The potential for automating database provisioning and integration -- especially given advances in Machine Learning and Artificial Intelligence -- is limited only by the imagination. 

The same goes for the potential of APIs which is why the aspersions cast upon the "composable enterprise" by RingCentral's Lee are not nearly damning enough to condemn APIs on the whole. To me, it's reminiscent of the Microsoft's Steve Ballmer and Oracle's Larry Ellison's early derision of the cloud. Both companies have done a complete about-face requiring an enormous investment to accelerate their catch-up strategies. After reading the latest API doomsday piece, you have to ask yourself if your company is truly prepared to take the same risk. 

The idea of the composable enterprise or as Lee puts it, "ultimate, infinite customization," is indeed a benefit of a wholly API-driven microservices IT architecture. But it's also the ultimate prize that, for existing businesses, can only be achieved after years of transformative work. If there was nothing to be had as a result of all that work except the pot of gold at the end of the rainbow, I would be inclined to side with Lee. But it's like saying there's really no point in playing regular season baseball since only two teams make it to the World Series. For pretty much any organization, the truth is that there so many other benefits that will be realized from embracing APIs (even if only in pockets of your company) that the journey will have been well worth the trip even if the so-called composable enterprise is never fully realized.

For example, simply rethinking your approach to IT as a services-oriented approach whereby all IT assets are programmatically accessible through relatively standardized channels (ie: HTTP APIs) will very naturally collapse the time and resources it takes to address one or more technological needs. For example, a new mobile application for the sales department needs to access customer or inventory data. The agility alone can make it possible for businesses to make life saving pivots in record time in response to competitive forces. As such assets are "servicized" with APIs, costly redundancies will likely surface. When properly designed and provisioned, API re-usability helps to drive out such inefficiences in ways that immediately accrue to profitability.

As your existing IT is decomposed into these discreet re-usable services -- some of which will be untraceable to your competitive advantage -- and your integrations are transformed from tight intertwinings to loose couplings, the resulting service compartmentalizations will result in new found flexibilty. For example, so long as there's no disruption to the specification (the so-called "contract") for the API that your suppliers access, maybe you can get rid of that money-pit-of-a-mainframe that provides it in favor of a smaller faster cheaper Stack that's on-premises or in the cloud. Or maybe you can outsource it altogether to a third party that not only does a better job of offering the service than you can, it provides it at a lower cost. 

When Amazon CEO Jeff Bezos penned his now infamous service-orient-yourselves-or-get-fired-mandate to his troops, I'm pretty sure he wasn't thinking in terms of the composable enterprise. Rather, he probably saw his company falling into the same trap that a great many other enterprises were already victims of; difficult-to-maintain, wasteful, costly, brittle and in some cases highly monolithic IT. He also knew what every CEO and business executive should know about their own IT; that it was a chain that had to be broken before Amazon's IT became its achilles heel instead of its source of efficiency and competitive advantage. 

To be honest, I don't think either author really believes his headline is genuinely representative of the state of APIs. Near the end of his post, Bloomberg says "the API lie is that data integration is an easy problem to solve." I agree. Integration is hard work. But a lot of people including me are thankful for the way HTTP APIs (RESTful or otherwise) have not only made that work significantly easier, they've opened new corridors of innovation. I detailed my concerns to Bloomberg who, via email, responded "Everything you say is quite correct. It just goes beyond the scope of my article. I love rebuttals!"

As for RingCentral's Lee, he concludes his post by saying "We can embrace the API economy without embracing this delusion. If software is 'eating the world,' as Marc Andreessen famously said, cloud APIs are its latest snack. They just aren’t the whole meal." While I wouldn't refer to the composabe enterprise as a delusion, I agree that you shouldn't view APIs as the answer to all your problems.

Via email, Lee told me "I certainly wrote that piece with the intent of generating conversation around this topic, thus the provocative title."  Mission accomplished (this rebuttal)! Lee continued, "But my point was definitely not to convey that APIs are not beneficial to enterprises. Keep in mind I run the developer program here at RingCentral.... so of course I'm a big believer of APIs driving material benefits in enterprises."

If you believe you haven't succeeded with APIs until your enterprise is 100% composable, you're dismissing more API benefits than I can possibly enumerate here and you're selling yourself short on the potential for APIs to change your organization's fortunes for decades to come. That said, those who commit to APIs today might not be surprised to wake up one day to the realization that their enteprise is is suddenly pretty composable. 

Be sure to read the next REST article: Just Because Github Has a GraphQL API Doesn’t Mean You Should Too