Blog article
See all stories »

APIs and the Abstraction of Cars

Car abstraction

In 2010, for the first time in history, we registered over a billion passenger cars on our roads, globally. It is estimated that by 2050, there will be 2.5 billion cars on our roads! Clearly, cars are a big part of our lives and will continue to stay for a while.

That being said, have you ever opened the bonnet of your car and had a look inside the engine compartment? It looks incredibly complex, with many individual parts each responsible for their own task. Look underneath your car the next time it’s raised up on a lift and notice how complicated the drivetrain and suspension are. Yet, despite being a massively complex machine, cars have become a fundamental part of lives – most of us are able to operate them with relative ease.

What makes this possible are the incredibly simple interfaces cars use to hide us from the complex internals of the car. The steering wheel allows us it change the direction of the car. The pedals allow us to change the speed (accelerate of decelerate) of the car. In fact, all the human interfaces within the car allow us to operate this incredibly complex piece of machinery with relative ease, by following simple standards.

APIs should adopt the same principle. The interface you expose to your API consumers should be as simple and easy as possible to understand. Complex internal integrations and business logic should not be exposed to your consumer – this is called abstraction; and it’s something the car does incredibly well. What it basically means is that a consumer of your API should not have to be concerned with understanding the internals of your API in order to use it.

That is not to say they should be completely oblivious or ignorant of the boundaries or relevant ancillary requirements of your API. Just like a driver of a car needs to know that a car needs fuel to run, air in its tires, keys to start, etc., so to should the consumer of your API be aware of any external constraints like intended audience, security, data structure, etc.

Another important aspect of a car that comes to mind is modularization, and I’ve mentioned it already. The complexity of a car is the sum of all its components working together; each performing their own unique function. Your API could be composed of internal components, orchestrated or composed to produce the functionality defined. I’ve discussed in my previous articles on “Making coffee to explain APIs” and “Most of us think we know what an API is but cannot seem to agree on what an API should be

 Photo by from Pexels


Comments: (0)

Craig Hughes
Blog group founder

Craig Hughes

VP Architecture

Emirates NBD

Member since

06 Sep 2018



Blog posts




More from Craig

Blog post

Chain of Trust

Blog post

API Misconceptions

Blog post

API Fragments - simple flexibility

Blog post

API: Arrays or named elements?

This post is from a series of posts in the group:


More generic posts and blogs relating with Application Programming Interfaces (APIs) including Open Banking and PSD2

See all

Now hiring