Customers of every business are engaging with companies on a variety of devices and channels including in-store, web, smartphones, tablets, laptops, and even connected devices in the burgeoning Internet of Things (IoT). What’s more, IT organizations are moving toward more efficient, agile development frameworks for internal use.

Customer and developer expectations are increasingly driving enterprise IT to employ new approaches to serving the needs of a diverse mix of users and experiences. That’s where application programming interfaces (APIs) come into play. They are the foundation upon which digital business is built, allowing app developers to create apps that can serve the needs of a specific segment of users.

APIs are not new in many industries, but with the explosion of apps and experiences required in the digital world, and new customer-centric IT organizations, companies across industries need better solutions than ever to manage their APIs and API-driven businesses. API management enables you to create, manage, secure, analyze, and scale APIs.

The Evolution of APIs

The term API may mean different things to different people, depending on the context. There are APIs for operating systems, applications, and the Web. For example, Windows provides APIs that are used by system hardware and applications. When you copy text or a picture from Microsoft PowerPoint to Word, the APIs are at work. Most operating environments provide an API so that programmers can write applications consistent with the operating environment. Today when you talk about APIs, you are probably referring to web APIs built using REST technologies. Hence, web APIs are synonymous to REST APIs. Web APIs allow you to expose your assets and services in a form that can be easily consumed by another application remotely over HTTP(s). The following describes the evolution of the modern-day web API:

Year 2000: Roy Thomas Fielding’s dissertation, “Architectural Styles and Design of Network Based Software Architectures,” is published.

February 2000: APIs are first demonstrated by SalesForce during the launch of its XML APIs at the IDG Demo 2000.

November 2000: eBay launches the eBay API, along with the eBay Developers Program. It is made available to a number of licensed eBay partners and developers.

July 2002: Amazon Web Services is launched. It allows third parties to search and display Amazon.com products in an XML format.

February 2004: Marks the beginning of the social media era, with Flickr launching its popular photo sharing site.

August 2004: Flickr launches its API, which help it to become the most preferred image platform. The Flickr API allows users to easily embed their Flickr photos into their blogs and social network streams.

June 2005: The Google Maps API launches, allowing developers to integrate Google Maps into their web sites. Today, over a million web sites use the Google Maps API, making it one of the most heavily used web application development APIs.

August 2006: Facebook launches its Developer API platform, allowing developers access to Facebook friends, photos, events, and profile information.

September 2006: Twitter introduces its APIs to the world in response to the growing usage of people scraping its web site or creating rogue APIs.

By the year 2006, web APIs are demonstrating the power of the Internet. They are being used to share content and made available to social networks. But they are still not considered fit for mainstream businesses. This year also marks the beginning of the cloud computing era. March 2006: Amazon S3 is launched. It provides a simple interface to retrieve and store any amount of data at anytime from anywhere on the Web.

September 2006: Amazon launches EC2, also known as the Elastic Compute Cloud platform. It provides resizable compute capacity in the cloud, allowing developers to launch different sizes of virtual servers within Amazon data centers. With cloud computing, web APIs witness their real power. APIs can now be used to deploy global infrastructure. APIs move from being used only for social fun and interaction to actually run real businesses. The emergence of mobile devices, smartphones, and app stores becomes the next big game changer.

March 2009: Foursquare is launched to provide a local search-and-discovery service mobile app. It provides a personalized local search experience for its users. By taking into account the places a user goes, the things they have told the app that they like, and the other users whose advice they trust, Foursquare aims to provide highly personalized recommendations on the best places to go near the user’s current location. By March 2013, the Foursquare API has more than 40,000 registered developers building a new generation of apps using of Foursquare’s location-aware services.

June 2009: Apple launches the iPhone 3G. iPod Touch and iPhone owners can download apps through iTunes desktop software or the App Store onto their devices. The APIs emerge as the driving force for the growth of the app economy.

October 2010: Instagram launched its photo-sharing iPhone app.

By 2012—after the introduction of powerful smartphones, iPads, tablets, and the growth of Android and Windows Mobile, the need for APIs to provide resources to build apps has grown exponentially. Mobile is the last piece in the digital strategy puzzle, which includes ecommerce, social media, and the cloud. The growth of Android smartphones and iPhones complemented the growth of digital technology, and APIs grew beyond powering ecommerce, social media, and the cloud to delivering valuable resources to the average person via smartphones. APIs make valuable resources modular, portable, and distributed. They have become the perfect channel for building apps for mobile devices, tablets, and handheld devices. Today, the success of the digital strategy for any company depends on the use of SMAC (social, mobile, analytics, and cloud) technologies—all powered by APIs.

Importance of Web-APIs

Simply put, Web-APIs are the medium to make a company’s digital assets consumable to any channel, which has a current or latent need. It helps companies to make the best out of the `Digital Core’, which has been developed over multiple years of effort and billions of dollars of investment. It helps create a wrapper of sorts around this Digital Core to make it more nimble by exposing the core functionalities in a more granular manner.

Figure 1: “WEB API” for web oriented digital APIs.

Defining an API and Its Characteristics:

In technical terms, an API defines the contract of a software component in terms of the protocol, data format, and the endpoint for two computer applications to communicate with each other over a network. In simple terms, APIs are a set of requirements that govern how two applications can talk to each other.

An API provides a framework for building services that can be consumed over HTTP by a wide range of clients running on different platforms, such as iPhone, tablets, smartphones, browsers, kiosks, connected cars, and so forth. These applications can be web applications or apps running on devices.

• The functionality provided.
• The location where the API can be accessed. An HTTP URL is normally used to specify the location.
• The input and output parameters for the API, such as parameter names, message format, and data types.
• The service-level agreement (SLA) that the API provider adheres to—such as response time, throughput, availability, and so forth.
• The technical requirements about the rate limits that control the number of requests that an app or user can make within a given period
• Any legal or business constraints on using the API. This can include commercial licensing terms, branding requirements, fees and payments for use, and so on.
• Documentation to aid the understanding of the API.

Optionally, the API provider may provide the following to aid developers in building and monitoring their apps:

• A portal on which developers can register themselves and their apps before they start using the APIs.
• Example programs and tutorials for using the APIs.
• A developer community forum and blogs to support developers and help them collaborate.
• Tools to expose and test the APIs.
• Health and usage information on the APIs used by developer apps

Types of APIs

Broadly classifying, APIs can be divided into two types: public APIs and private APIs (see Figure 1-2). Going by name, public APIs are open to all for use. Private APIs, on the other hand, are accessible only by a restricted group. Private APIs may be for B2B partner integrations or for internal use. Those used for partner integration are also known as partner APIs. Those for internal use are referred to as internal APIs. An internal API can ease and streamline internal application integrations. It can also be used by internal developers for building mobile apps for an organization’s own use.

Figure 2: Types of APIs

Why API Management

Customers today want to have access to enterprise data and services through a variety of digital devices and channels. To meet customer expectations, enterprises need to open their assets in an agile, flexible, secure, and scalable manner. APIs form the window into an enterprise’s data and services. They allow applications to easily communicate with each other using a lightweight protocol like HTTP. Developers use APIs to write applications that interact with the back-end system. Once an API has been created, it needs to be managed using an API management platform. An API management platform helps an organization publish APIs to internal, partner, and external developers to unlock the unique potential of their assets. It provides the core capabilities to ensure a successful API program through developer engagement, business insights, analytics, security, and protection.

An API management platform helps business accelerate outreach across digital channels, drive partner adoption, monetize digital assets, and provide analytics to optimize investments in digital transformation. These platforms offer pre-built sets of functionalities, which can be quickly configured to achieve most generic requirements from an API management perspective.

Figure 3: API management offerings

Anatomy of an API management solution

An API management platform enables you to create, analyze, and manage APIs in a secure and scalable environment (see Figure 4). An API management platform should provide the following capabilities: • Developer Enablement for APIs
• Secure, Reliable and Flexible Communications • API lifecycle Management • API Auditing, Logging and Analytics

Figure 4: API management capabilities

API management capabilities can be delivered by any API management vendor in a public cloud as a hosted service or can be deployed on-premise in a private cloud. A hybrid approach can also be followed, with some components of the API management platform being offered as a hosted solution and others deployed on-premise for increased security and control.

An API management platform provides these capabilities as three major types of services (and as illustrated in Figure 5):

1. API gateway services allow you to create and manage APIs from existing data and services. They allow you to add security, traffic management, interface translation, orchestration, and routing capabilities into your API.
2. Analytics services monitor traffic from individual apps and provide business with insight and operational metrics, API and app performance, and developer engagement metrics.
3. Developer portals provide capabilities for developer and app registration and onboarding, API documentation, community management, and API monetization.

Figure 5: API management platform services

Below are the functionalities offered by an API Management Platform

The API Gateway

An API gateway forms the heart of any API management solution that enables secure, flexible, and reliable communication between the back-end services and digital apps (see Figure 6). It helps to expose, secure, and manage back-end data and services as RESTful APIs. It provides a framework to create a facade in front of the back-end services. This facade intercepts the API requests to enforce security, validate data, transform messages, throttle traffic, and finally route it to the back-end service. The static response may be cached to improve the performance. The API gateway can optionally orchestrate requests between multiple back-end services and also connect to databases to service the request. All of these functionalities can be implemented in a gateway, mostly through configurations and scripting extensions

Figure 6: API Gateway capabilities

API Security

APIs provide access to valuable and protected data and assets. Therefore, security for APIs is of utmost importance to protect the underlying assets from unauthenticated and unauthorized access. Due to the programmatic nature of APIs and their accessibility over the public cloud, they are also prone to a different kind of threat attack. The API management platform should therefore address the following aspects of API security.

Authentication: Authentication is the process of uniquely determining and validating the identity of a client. An app acts like a client making an API call. It is a piece of software that consumes an API to get access to enterprise assets, data, and services. It can run on the Internet, a computer, smartphones, tablets, or any other electronic device. Apps are usually made available by their developers through a distribution platform, such as Apple’s App Store, or Google Play, or the Windows Phone Store. Every app is identified by its name and a unique UUID known as the app key. The app key often serves as an identity for the app making a call to the API. It is normally issued and managed via the API management platform of the API provider. An app key is also known as an API key, an app ID, or a client ID. The API management platform must have the ability to issue, track, and revoke the app key. Authentication services may also require integration with identity management systems that control user access to applications and other services.

Authorization: Authorization controls the level of access that is provided to an app making an API call. It controls which API resources and methods that an app can invoke. When an app makes an API call, it normally passes an OAuth access token in the HTTP headers. This token is generated as part of the OAuth handshake and is associated with scopes that determine the APIs that can be accessed using the token. An access token can be associated with one or multiple scopes. Each access token may have an expiry duration that controls the duration for which the token is valid. If the token is expired, a new access token would be required to be generated. An app can do this automatically by presenting a refresh token. The refresh token may be exchanged to get a new access token with a renewed validity period. The use of a refresh token by an app to regenerate the access token helps to improve the overall user experience.

Identity mediation: APIs normally use OAuth protocols for implementing security. However, the back-end services may be secured using SAML or any other WS-Security headers. Hence, the API management platform must have the capability to integrate with back-end IDM platforms and do identity mediation. OAuth to SAML is a very common identity mediation requirement.

Data privacy: APIs expose data that may be sensitive; such data should be visible only to its intended recipient. Any sensitive data in transit should be encrypted. If such data gets logged anywhere, it must be masked. The API management platform must therefore possess data privacy capabilities. Data privacy can be achieved through encryption and data masking. Sensitive data should be encrypted with digital certificates in transit. The API management platform should have support for SSL/TLS. For some use cases, additional encryption of specific elements within the payload may also be required. Masking sensitive data at rest within audits and log files is yet another data privacy requirement that an API management platform should provide.

Key and certificate management: The API management platform should also provide the capability to manage keys and certificates required for data privacy.

DoS protection: APIs open valuable data and assets outside the firewalls of the enterprise. This increases the attack surface and makes them more prone to attacks. Hackers may try to bring down back-end systems by pumping unexpectedly high traffic through the APIs. Denial-of-service (DoS) attacks are very common on APIs. Hence, the API management platform should be able to detect and stop such attacks.

Threat detection: For public APIs, the likelihood of bad actors making attacks using malicious content is high. Content-based attacks can be in the form of malformed XML or JSON, malicious scripts, or SQL within the payload. Such attacks can also happen to private and enterprise APIs. The API management platform should be able to identify malformed request formats or malicious content within the payload and then protect against such attacks. Error visualization capability can also help detect any hacker attempting to find an exploitable weakness in APIs.

API Traffic Management

Depending on the nature of data and services provided by the API, traffic management offers a different business value to different classes of customers. Each customer class may be willing to pay differently for access. For example, some app developers prefer to try out APIs for free. The API provider may provision such users to make a small number of API calls in a day/week/month. Paying customers, however, want access to a higher or an unlimited number of API calls. Again, the API provider may allow customers a different level of access depending on their location or the time of the day; for example, internal enterprise users may get unlimited access to a high-performing API, whereas public Internet users may have limited access. More API calls may be allowed during off-peak hours but there is a limited number allowed during peak business hours. The API provider may have different requirements to throttle and manage the API traffic. The API platform should provide the following capabilities for traffic management.

Consumption quota: Defines the number of API calls that an app is allowed to make to the back end over a given time interval. Calls exceeding the quota limit may be throttled or halted. The quota allowed for an app depends on the business policy and monetization model of the API. A common purpose for a quota is to divide developers into categories, each of which has a different quota and thus a different relationship with the API. For example, free developers who sign up might be allowed to make a small number of calls. But paid developers (after their verification) might be allowed to make a higher number of calls.

Spike arrest: Identifies an unexpected rise in the API traffic. It helps to protect back-end systems that are not designed to handle a high load. API traffic volume exceeding the spike arrest limit may be dropped by the API management platform to protect back-end systems in the event of DoS attacks.

Usage throttling: Provides a mechanism to slow down subsequent API calls. This can help to improve the overall performance and reduce impacts during peak hours. It helps to ensure that the API infrastructure is not slowed down by high volumes of requests from a certain group of customers or apps.

Traffic prioritization: Helps the API management platform determine which class of customers should be given higher priority. API calls from high-priority customers should be processed first. Not all API management platforms support this capability. Hence, an alternative approach or design may be required to implement traffic prioritization.

Interface Translation

When an enterprise creates an API to expose its data and services, it needs to ensure that the API interface is intuitive enough for developers to easily use. APIs should be created with an API-First approach, which promotes API creation with a consumer focus. Hence, the interface for the API will most likely be different from that of the back-end services that it exposes. The API gateway should therefore be able to transform the API interface to a form that the back end can understand. To support interface translation, the API gateway should support the following:

Format translation: The back-end system might expect data in SOAP, or XML, or CSV or any other proprietary format. Such data format cannot be easily consumed by the API consumer. Hence, the API gateway should have the capability to easily transform from one format to other. Most API management platforms provide the capability to transform data from XML to JSON (and vice versa) with a one-to-one mapping of the data elements. Mapping from JSON to any other data format may be supported through customization.

Protocol translation: Most back-end systems that host services provide a SOAP interface for consumers. However, SOAP is not a protocol that is suitable for APIs to build apps for digital devices. API management platforms must be able to do a protocol transformation from SOAP to REST to provide a lightweight interface for consumers. Support for other protocol transformations—like HTTP(s) to JMS/FTP/JDBC—may be a nice to have feature in the API management platform.

Service and data mapping: An API management platform should provide a graphical representation of the different back-end service component that maps to provide an API service. It should incorporate service mapping tools that enable the discovery and description of existing service delivery assets so that they can be wired into your API design.

Caching

Caching is a mechanism to optimize performance by responding to requests with static responses stored in-memory. An API proxy can store back-end responses that do not change frequently in memory. As apps make requests on the same URI, the cached response can be used to respond instead of forwarding those requests to the back-end server. Thus caching can help to improve an API’s performance through reduced latency and network traffic.

Similarly, some static data required for request processing may also be stored in-memory. Instead of referring to the main data source each time, such data can be retrieved from the cache for processing the request. An expiry date/time can be set for the cached data or the data can be invalidated based on defined business rules. If the data is expired, new data would be retrieved from the original data source and the cache would be refreshed with the updated data.

Service Routing

APIs need to route requests from consumers to the right back-end service providing the business functionality. There may be one more backend systems providing the backend functionality. Hence, the API management platform should be able to identify and route the request to the correct instance of the back-end. The API management platform should support the following routing capabilities:

URL mapping: The path of the incoming URL may be different from that of the back-end service. A URL mapping capability allows the platform to change the path in the incoming URL to that of the back-end service. This URL mapping happens at runtime so that the requested resource is retrieved by the consumer via service dispatching.

Service dispatching: This allows the API management platform to select and invoke the right back-end service. In some cases, multiple services may have to be invoked to perform some sort of orchestration and return an aggregated response to the consumer.

Connection pooling: The API management platform should be able to maintain a pool of connections to the back-end service. Connection pooling improves overall performance. Also, it may be required for traffic management purposes to ensure that only a fixed maximum number of active connections are opened at any point in time to the back-end service.

Load balancing: Load balancing helps to distribute API traffic to the back-end services. Various load balancing algorithms may be supported. Based on the selected algorithm, the requests must be routed to the appropriate resource that is hosting the service. Load balancing capabilities also improve the overall performance of an API.

Service Orchestration

In many scenarios, the API gateway may need to invoke multiple back-end services in a particular sequence or in parallel and then send an aggregated response to the client. This is known as service orchestration. The service orchestration capability helps to create a coarse-grained service by combining the results of multiple back-end services invocation. This helps to improve overall performance of the client by reducing latency introduced due to multiple API calls. Service orchestration capability may require the API gateway to maintain states in-between the API calls. However, the API gateway should be kept as light and stateless as possible. Hence, it is recommended that the API gateway only be involved in the orchestration of read-only services that are non-transactional in nature.

API Security Patterns

When APIs provide access to enterprise data and assets to a wide audience, they are also opening a larger variety of threats and security challenges for the company. The number of malicious assault and denial-of-service (DOS) attacks are increasing as APIs make back-end systems more accessible. Since APIs can be accessed programmatically, the vulnerability is even greater. Hence, over time, new security patterns have emerged to secure the access to APIs and protect back-end systems against various attacks. The challenge is in providing an easy access to legitimate and authorized users while making it difficult for unauthorized users to access APIs. Hence, getting API security right can be a challenge. This section looks at the different approaches that have emerged as patterns for securing APIs against various types of attacks from potential hackers.

Common Forms of Attack

Hackers can attack to get access to the system, steal valuable information, or even bring down the system that impacts your business. The following are the most common forms of attack on APIs.

DoS attacks: Malicious users flood your system with high-volume API traffic that the back-end systems cannot handle, bringing it to a halt.

Scripting attacks: In this kind of attack, attackers inject malicious code into the system to get access and possibly tamper back-end data and assets. The malicious code can be an SQL statement, XPath or XQuery statement, or some script that tries to exploit design flows in the system to get access to back-end data.

Eavesdropping: In this kind of attack, the hacker gets access to an API request or response while the data is in transit over a nonsecure API communication channel. He can then manipulate the message and send it to the ultimate recipient.

Session attack: In this kind of attack, the hackers gain access to the session ID used by a user or app. This information is then used for personification and access to the user’s account and resources. In this common form of attack, an app makes an API call and passes the credentials or session information in the header, that can provide access to the underlying assets. The risk is worse in scenarios that use a multiparty authentication scheme, such as OAuth, to grant permissions to a third party to access to access their private data.

Cross-site scripting (XSS): This is a special form of scripting attack that takes advantage of known vulnerabilities in a web site or web application. An attacker injects a malicious link or code that is executed on the victim’s web browser. This form of attack bypasses the same-origin policy that requires everything on a web page to come from the same source. When a same-origin policy is not enforced, the attacker can inject a script or modify the web page to achieve their purpose. An XSS attack delivers tainted content to the API from a trusted source that has permissions to the system. Hence, the API must protect itself by validating the 'Origin' header in the request payload to check for the origin before allowing access to back-end resources.

API Risk Mitigation Best Practices

There are different approaches and patterns that have emerged to protect APIs from various forms of security threats and provide comprehensive security. The approaches for securing APIs should control access to APIs as well as monitor and limit API usage. Controlling access to an API should authenticate and authorize users or apps making API calls. It should also scan incoming messages for well-formedness and any potential threats in it. A monitoring approach should detect any sudden changes in the API traffic pattern and block the user from making calls. A comprehensive API security approach should look at all the links in API value chain: starting from the users and apps that consume the API, to the API team that builds the API, all the way to the API provider that exposes the data and services in the back-end systems. Since APIs provide omnichannel access, the API security approaches should also be omnichannel security. The security architecture should be flexible and responsive enough to prevent, detect, and react to all forms of API threats in near real time.

Top API Management Tools

Let’s explore the most popular API Management Tools that are available in the market.

References:

1. https://www.softwaretestinghelp.com/api-management-tools/
2. https://kupdf.net/queue/api-management-a_5a67a008e2b6f5606f609129_pdf?queue_id=-1&x=1641361305&z=MTAzLjIwNi4xMDQuNg==
3. https://cloud.google.com/files/apigee/apigee-definite-guide-to-api-management-ebook.pdf