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. ]
