4 misconceptions about APIs

4 misconceptions about APIs

APIs have evolved steadily and soothed development complexity, but some common misunderstandings remain

99 readers like this
CIO Delivering apps faster byod

Application programming interfaces (APIs) have gone from the new tech kid on the block to an industry standard for building software applications. As the key means for sharing data among disparate applications, the practical applications of APIs are everywhere – from online restaurant reservations to electronic payments to real-time inventory management for online retailers.

[ Read our related articles: How to explain APIs in plain English and APIs and microservices: 4 trends for IT leaders. ]

Yet despite that wide API usage, some CIOs remain reluctant about the development approach. Let’s examine some common misconceptions that may be holding them back.

Misconception 1: APIs will be limited to one area of my business

APIs can be applied to different areas of a company without the need to build from scratch. With pre-built integration templates and workflows, a business unit or department can use the same data from an existing API and repurpose it based on their specific requirements. Using the same inputs, these API libraries become the framework for producing different outputs.

For example, a company may build an API to manage online marketing strategy using consumer behavior data gathered from its marketing analytics system. The assets stored in this API library can then be reused or fragmented to produce different information needed for the purchasing department. In other words, the API library may be broken down in for marketing purposes as 3+2, while the same data may be reused for the needs of the purchasing department as 1+1+1+1+1.

Misconception 2: APIs are singular in nature or application-specific

In first-generation APIs, web services would provide or pipeline the data based on a single application requirement. Today, the same API can be used again and again for multiple functions without having to modify the application and without burdening the application team. These modern APIs can produce different data styles and formats based on customer needs.

We can think of this in the same way we think of color printer technology. We do not need separate printers to print a document in varying colors. Rather, a standard color printer will combine proportions of three standard ink colors – cyan, magenta, and yellow – to produce a wide range of colors from the same printer. Likewise, a single API can facilitate different application needs by pulling different assets from server-side repositories.

Misconception 3: APIs can only be accessed or modified by API developers

In the past, APIs that were developed to run continuously did not allow other users to touch any code. Users were able to unlock data, but access and management of the data were limited to the specific data teams.

That changed with the introduction of Anypoint Exchange, which promotes user interaction and modifications and allows a single API to be used by multiple users. With an API key, users no longer need to wait for the API developer to make application changes. Instead, Anypoint Exchange allows users to access proven assets – connectors, templates, examples, and RAMLs – from the repository center and add to or reuse them without harming or altering the application.

Misconception 4: Every API change requires hardcode development /downtime

Imagine being able to change your car’s oil while the vehicle is in motion. Although not a reality for cars (yet), this is the standard for APIs. Unlike legacy APIs, which required hard-coding development and thus significant downtime with every modification, modern APIs do not keep hard-coded features. Rather than building new API stored procedures, SQL syntax, or other formatting every time there is an application change, modern APIs can pull stored procedures or stored templates from different repositories without stopping the application.

[ Get the related eBook: 8 steps to cloud-native application development. ]

Zeeshan joined Prime TSR in 2018 to amplify the consultancy’s work in AWS, Azure, and SaaS. Described by colleagues as a diplomat who excels at conflict resolution, Zeeshan has spent over a decade managing complex projects and providing best-in-class service for blue-chip companies including McDonald’s, Allstate, Verizon, Motorola Solutions and Siemens.

7 New CIO Rules of Road

CIOs: We welcome you to join the conversation

Related Topics

Submitted By Kevin Casey
May 27, 2020

What do successful Kubernetes migration projects have in common? A clear strategy, a strong culture, and the proper resources to execute the plan. Check out this expert advice

Submitted By Rick Huff
May 27, 2020

Rick Huff started as CIO at Paycor on March 9, 2020 – just in time to get a front row seat to a pandemic. Here's what he learned about handling a crisis in real time.

Submitted By Jaeson Paul
May 27, 2020

Leaders don't get the insight they need by simply asking for it: In fact, you may be derailing discussions before they start. Here's how to encourage honest feedback – and how to respond.


Email Capture

Keep up with the latest thoughts, strategies, and insights from CIOs & IT leaders.