4 misconceptions about APIs

4 misconceptions about APIs

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

43 readers like this


February 08, 2019
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. At Prime TSR, Zeeshan collaborates with cross-functional teams to develop and integrate mobile and web-based APIs with existing management systems.

7 New CIO Rules of Road

CIOs: We welcome you to join the conversation

Related Topics

Submitted By Robert Reeves
July 17, 2019

It's easy to put off DevOps as just another trend: Culture change is hard. But your competitors aren't waiting.

Submitted By Stephanie Overby
July 16, 2019

Before you can get in the door to interview for a new job, you must get past the AI tools that screen candidate resumes. Experts share seven do’s and don’ts for AI-proofing your resume.

Submitted By Chris Fielding
July 16, 2019

Digital transformation requires that all of your systems communicate. How can they possibly communicate if they can’t speak the same language? A CIO’s lessons learned.


Email Capture

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