How to Win with APIs - Part 2

Defining APIs: Lightweight APIs and Data APIs

In my previous post, I discussed the “API first” approach and API hub as essential ingredients for a successful data management strategy. As “API first” approach suggests that we define the API first, it makes us think about its purpose. This gives rise to some fundamental questions. What need is it intended to address? Who is the consumer? Do we expect it to be mass-consumed? What data does it require and provide? And so on. Once these questions are answered, you’d probably be able to classify your API to a lightweight API or data API. Let’s discuss those in this blog post.

Lightweight APIs

These are typically RESTful APIs that are swift and usually work with small data sets’ payloads. These APIs may need to face load/mass consumption (note: it’s a good idea to use caching here). APIs for fetching images, geolocation, translation, and stocks information are just a few examples of lightweight APIs. Where the response needs to be near real-time quick and light, the footprint on the provider side is usually minimal. Can you think of a typical use case where lightweight APIs are critical? That’s right – Mobile (but not exclusively). At times, lightweight APIs are commercialized, so API providers monetize, meter and bill the consumption of their APIs.

Data APIs

Data APIs are a different story. These are APIs that serve a business purpose. They need to be secured, managed and monitored. While speed and performance are critical in lightweight APIs, data APIs have the following traits:

Business oriented

Data APIs trigger business transactions of some sort. Data APIs are based on underlying business processes that are initiated, including a series of services interactions and backend calls often referred to as “orchestration.” Some examples for data APIs include: order-to-bill, procure-to-pay, onboarding new employees, quote-to-cache, and more. It is reasonable to conclude that data APIs have some impact on the business. In more technical terms, these APIs are not for ‘read-only’, but also have ‘write’ actions.

Secured

Data APIs are SSL/HTTPS based, usually encrypted and certified. While lightweight APIs are often open to the public, data APIs require governance, with authentication and authorization mechanisms in place. Simple ones include username-password (Basic) or JWT token based, but also Oauth2/OpenID Connect, which sometimes requirethird party providers.

Managed

Data APIs have business orientation and it would be best to have the APIs managed. As mentioned in my previous blog post, it usually means that you will want to have an API hub, or an API management tool in place either locally or as a service. By managed it means that the API has a lifecycle, for example versioning. It has policies, such as IP filtering and rate limit that can be defined and enforced. With API management tools, APIs are easily searched and discovered for better and efficient consumption. Once the APIs are consumed, the usage of the APIs is controlled and constantly monitored. The monitoring sheds light on the usage, errors, access-violations as well as trends.

Cloud-based

While the characteristics of data APIs that I have mentioned above are a must, cloud-based data APIs is a growing and evolving integration pattern. Nowadays, companies are seeking ways to better integrate and exchange data with partners and customers while exposing data APIs in the cloud. By using an API hub in the cloud, with tight governance and security mentioned above, data APIs can be easily consumed. When the API hub is integrated into an iPaaS some of the integration and transformation can be done in the cloud while connecting to backend and external resources when needed.

For more on API management, check out my other posts in the series: A Successful API Strategy; and The Rise of API Management. And stay tuned for my fourth post coming soon on API implementation and management in Informatica iPaaS.

Learn more about Informatica API management.