Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Why Every API Is Different

DZone's Guide to

Why Every API Is Different

Many companies behind APIs aren't interested in being open with others in their industry, resulting in a narrow and selfish focus when it comes to API design patterns.

· Integration Zone
Free Resource

Learn how API management supports better integration in Achieving Enterprise Agility with Microservices and API Management, brought to you in partnership with 3scale

I enjoy having conversations with "normals" about APIs, especially when they approach me after doing a great deal of research and are pretty knowledgeable about the landscape, even if they may lack deeper awareness around the technical details. These conversations are important to me because it's these folks who will make the biggest impact with APIs — it won't be the entrepreneurs, developers, architects, and us true believers.

While having one of these conversations yesterday, the topic of API design came up, and we were talking about the differences between seemingly similar APIs like Flickr and Instagram, or maybe Twitter and Facebook. I was asked:

"Why are these APIs are so different? I thought the whole thing with APIs is that they are interoperable and make integration easier?"

I love getting asked this because it helps me see the API space for what it is, not the delusion that many of us API believers are peddling. 

So, why are the designs of APIs so different, even between seemingly similar APIs?

Integration 

APIs make integration into web, mobile, and devices apps easier. They also make integration with other systems easier. However, very few API providers truly want their APIs to work seamlessly with the competition!

Silos 

Many API providers operate in silos, and I have encountered teams who do almost no due diligence on existing API design patterns and standards or even look at the potential competition and what already exists before crafting their API design strategy. 

Intellectual Property

Not many folks see the separation between their API design, the naming, ordering, and structure of the interface, and their backend API code, resulting in some distorted views of what is proprietary and what is not.

Venture Capital

The investors in many companies behind APIs are not interested in being open and interoperable with others in their industry, resulting in a pretty narrow and selfish focus when it comes to API design patterns.

These are just a handful of the reasons why APIs are so different. It can be hard for people not immersed in the world of technology to cut through the hype, walled-garden belief systems, and delusions we peddle in the world of APIs. What makes it even worse is when you see APIs become a facade for a variety of industries and begin masking the unique hype, belief systems, and delusions that exist in these verticals.

When you are only focused on the technology of APIs this all seems simple and pretty straightforward. Once you begin layering in the business of APIs, things get more complicated — but they are doable. It is when you start considering the politics of APIs that you begin to see the darker motivations behind doing APIs, more of the illnesses that plague the API sector and infect each vertical they touch. All of this contributes to many APIs never living up to the hype, or even pragmatic expectations, and this will continue to hurt the bottom line of companies who are doing APIs. 

Unleash the power of your APIs with future-proof API management - Create your account and start your free trial today, brought to you in partnership with 3scale.

Topics:
integration ,api design ,apis

Published at DZone with permission of Kin Lane, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

THE DZONE NEWSLETTER

Dev Resources & Solutions Straight to Your Inbox

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.

X

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}