… because it's a terrific metaphor for complex systems - and the challenge of assembling them.

Lately I've been using the figure below as a metaphor for complex end-to-end IoT projects, and the challenge of integrating them.

My point is simply that you wouldn't expect to assemble this car (in case you're interested, a Volkswagen Golf) using just a crescent wrench, so likewise you shouldn't expect to integrate end-to-end IoT projects using just RESTful API's.

Now don't get me wrong - I have nothing against API's. They are the defacto choice for interoperability between distributed components in most innovative IT projects lately, particular those involving mobile, cloud and IoT.

And I predicted the wide-spread adoption of API's in B2B, even in traditional B2B contexts.

But the point I am making here is that RESTful APIs - alone - often lack all the capabilities you need to address functional gaps and to scale up end-to-end IoT projects.

When you discuss back-end system integration with an IoT solution provider and they say, “We have an API for that”, don't be seduced by the idea that API's, alone, will address all your needs. Consider:

Semantic reconciliation: Either the API publisher, API consumer or an intermediary must address the frequently occurring semantic miss-match between distributed computing endpoints. The point is that you often need to translate data and to do this in scale you will often leverage integration middleware (e.g., iPaaS, ESB or integration brokerage).

Protocol-hopping: The reality is that RESTful isn't always available, so you often need to protocol-hop between different forms of communications (e.g., RESTful to SOAP / MOM / whatever).

At times your IoT platform middleware will support needed non-RESTful protocols, but often you'll benefit (again) from integration middleware, most which offer a portfolio (sometimes dozens) of supported protocols.

Adapters: Most SaaS and more recent versions of mainstream enterprise software (e.g., from Infor, Oracle, SAP) support API's. But often older versions of this software, legacy Apps and data, and applications and databases from many smaller or more verticalised IT providers do not support any form of API (let alone RESTful ones).

In this case you may need commercial adapters or ADK's (adapter development kits) to “API enable” such applications and data.

Governance: While RESTful API's address many basic security and QoS needs, more demanding IoT applications may require stronger security, higher performance monitoring and other (e.g., public compliance) forms of governance. API management tools (either integration middleware stand-alone tools or embedded API management capabilities) are often use by IoT project implementers to define and manage API policies, and enforce them at runtime.

What am I missing? Regardless, the take-away here is that indeed - Yes! - go ahead and adopt an “API First” approach to interoperability for your IoT projects and - Yes! - in many cases simpler, smaller-scale IoT projects can be successfully deployed and integrated using just RESTful API's As-Is.

But in the same way that a crescent wrench - alone - likely isn't enough to assemble a car, so too RESTful APIs - alone - likely won't address all your IoT integration needs.

As IoT projects proliferate, become more complex, and scale up also be prepared to leverage some form of integration middleware to address functionality gaps.