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 rawpixel.com from Pexels

6368
External | what does this mean?
This content is provided by an external author without editing by Finextra. It expresses the views and opinions of the author.

Comments: (0)

Craig Hughes

Craig Hughes

Lead Enterprise Architect API

Danske Bank

Member since

06 Sep

Location

Copenhagen

Blog posts

11

Comments

3

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

API

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


See all