Application programming interface (API)

Application programming interface (API) is a set of codes, protocols, and tools for querying data, parsing responses, and sending instructions between one software platform and another. It allows communication between software programs. APIs have often been described as any sort of generic connectivity interface to an application; however, APIs have taken on some characteristics that make them useful and valuable:

• APIs adhere to standards (typically HTTP and REST) that are developer-friendly, easily accessible, and broadly understood.
• APIs are treated more like products than code and are designed for consumption for specific audiences, are documented, and are versioned in a way that provides expectations for users on an API's lifecycle and maintenance.
• Because APIs are more standardized, they have a stronger discipline for security and governance and are monitored and managed for performance and scale.
• As any productized software, APIs have a software development lifecycle of designing, testing, building, managing, and versioning.

APIs are used for communication between services, such as embedding a popular function like Google Maps into a website or app using the Google Maps API to embed the map. This means if the Google Maps API did not exist, any website or application that wanted to have an interactive map would have to take the time to develop its own interactive map. Whereas the Google Map API allows sites and apps to have access to a consistent map experience.

As a set of defined rules for computers and applications to communicate with one another, APIs sit between an application and the web server, acting as an intermediary layer that processes data transfer between systems. To do this, an API follows a familiar pattern:

• A client application initiates an API call to retrieve information—also known as a request. The request is processed from an application to the web server via the API's Uniform Resource Identifier (URI) and includes a request verb, headers, and sometimes a request body.
• After receiving a valid request, the API makes a call to the external program or web server.
• The server sends a response to the API with the requested information.
• The API transfers the data to the initial requesting application.

Visualization of how an API works.

While data transfer differs depending on the web service being used, this process of requests and response happens through an API. And where the user interface is designed to be used by humans, APIs are designed for use by a computer or application. APIs offer security because their position as middleman facilitates the abstraction of functionality between two systems. API calls also usually include authorization credentials to reduce the risk of attacks on the server, and an API gateway can limit access to minimize security threats. Also, during an exchange, HTTP headers, cookies, or query string parameters provide additional security layers to the data.

Because APIs allow companies to open up access to their resources while maintaining security and control, they offer valuable aspects for businesses. Some popular examples of application interfaces users may encounter include the following:

• Universal logins—a popular API example is the function that enables people to log in to websites using a Facebook, Twitter, or Google profile login details. This feature can allow any website to leverage an API from one of the more popular services to quickly authenticate the user, saving them the time and hassle of setting up a new profile for every website service or new membership.
• Third-party payment processing—these APIs allow users to pay for products online without exposing any sensitive data or granting access to unauthorized individuals, such as the now-ubiquitous "Pay with PayPal" function often seen on e-commerce websites.
• Travel booking comparisons—travel booking sites aggregate thousands of flights, showcasing the cheapest options for every date and destination. This service is made possible through APIs that provide application users with access to the latest information about availability from hotels and airlines. Through autonomous data exchanges, APIs can reduce the time and effort involved in checking for availability.
• Google Maps—one of the most common API examples, Google Maps allows for the display of static or interactive maps; the app utilizes other APIs and features to provide users with directions or points of interest.
• Twitter—the Twitter API can allow developers to post tweets via an API with Twitter, making public tweets and replies available to developers. Each tweet contains descriptive core attributes, including an author, a unique ID, a message, a timestamp, and geolocation data.

Example of a breakdown of an API strategy.

Before a developer or an enterprise builds an API, to be successful it is considered best practice to develop an API strategy. The API strategy is a blueprint for the API and a digital-first initiative and can include what the goal for an API for the developer is. That is to say, an API strategy has to outline what the API is going to do, who the API is being built for, and how the API can create success for the larger enterprise. There are various approaches to building an API strategy, which depend partly on the organization and the goals of the API. However, a common and simple API strategy blueprint can break down the development of the strategy into four digestible and practical stages:

• Establish a digital strategy
• Align the organization and culture
• Evaluate, build, and deploy the supporting technology
• Engage an ecosystem

Generally, once an API strategy has been developed and defined, it will inform the approach toward the API's architecture and the processes of building the architecture and will bleed into the management of the API. That management addresses the needs of developers, applications, users, and the business in a cohesive manner. The strategy and the later management of an API can include the following considerations:

• Does the API provide the features and functionality the application and users need?
• How does the business control the API's release and future development?
• Does the API provide enough authorization and authentication to guard business data and workloads from unauthorized access or alteration, and is the API security adequately tested during development?
• How is the API being used, and what changes will be made to improve API utilization and performance?
• Does the API support the business strategy, and does it support the business's regulatory compliance requirements?

An API strategy can help an organization toward a digitization strategy and can be a part of a digitization strategy. However, the API strategy can help an enterprise understand how it can use an API to engage customers through web, mobile, and social apps. And by developing private APIs, a business can offer employees and partners new tools to help streamline operations and better serve customers.

Often APIs are a part of the digitization or modernization strategies for enterprises. The proliferation of APIs across industries has driven this growth and has driven more enterprises to develop APIs to modernize their business. Modernization efforts come with new sets of challenges and necessitate the above enterprise strategy capable of encompassing the full API cycle for public and private APIs. When deciding, as an enterprise, to modernize or digitize and develop APIs, the API strategy can be incredibly important as it can help an organization understand the hidden costs, challenges, and cultural shifts that are associated with developing APIs and offering APIs as a product.

Enterprise modernization using APIs has become more common as the "API Economy" has continued to grow, becoming a key part of digital transformation and considered by many to be a must for agile businesses. To help an organization through this modernization process and development of APIs, it is considered to be best practice to keep API documentation up-to-date, accurate, and easy to read; track success with applicable metrics; and build a community of developers, while ensuring to engage that community.

API management, as mentioned above in API strategy, is the process of designing, publishing, documenting, and analyzing APIs in a secure environment. While the API strategy and management are similar, the API strategy can be considered a conceptual and research step, whereas the API management is a procedural step. API management can be developed by an organization, but the more popular approach is to use an API management solution, which an organization can employ to guarantee public and private APIs are consumable and secure. Most API management solutions generally include the following capabilities:

• A developer portal—the developer portal is a common best-practice for API management, and it tends to provide API documentation along with developer onboarding processes, such as signup and account administration.
• An API gateway—an API gateway is a single point of entry for clients and determines how clients interact with APIs through the use of policies.
• API lifecycle management—as the name implies, lifecycle management includes the design and implementation, until the retirement of the API.
• Analytics—analytics are important to know what is going on with an API or which consumer or app is calling each API and how often.
• Support for API monetization—often API management platforms can allow developers to monetize their APIs through usage contracts and to define the terms or subscription tiers of those contracts depending on the monetization strategy of an API developer.

Further, a part of API management is the protection and securing of the API, which will depend on the architecture used in the API. Security, much like analytics, involves transparency into the use of the developer's APIs, which is enabled by the API management platform. API management can also help developers increase the lifecycle of their APIs, iterate upon the APIs, and not need to retire APIs when their use cases and popular uses begin to change. API management can also help organizations manage API integrations across growing numbers of systems and applications and gives these organizations greater flexibility when APIs grow in scalability.

When building an API product and managing the API product over time, developer experience, especially when developers are an API's main customers, should be the top priority. To ensure this is the case, usability testing can be undertaken to ensure the API offers a consistent and best possible experience and that the API performs as intended under various conditions. This type of testing should take place through all stages of the development of an API. To get as much as possible out of testing, there needs to be some preparation, which can include the following:

• Define an explicit task to test
• Give as little information as possible, but enough to start a test
• Find a way to observe the user when using an API
• Make sure the user logs their account of testing a product
• Provide a chance for the tester to ask questions throughout the process
• Create a detailed report of observations during the test
• Derive learnings and tasks from the observations
• Share the learnings to inform development and iteration

While organizations can undertake usability with their own teams, API management platforms can offer usability testing and related testing to help the organizations maintain the API. An organization can also employ an outside organization to go through the API and provide feedback on their testing. This can, as noted above, help define development strategies and iteration strategies to ensure developers receive a consistent experience and can keep their API product competitive.

The continuous integration and continuous deployment (CI/CD) pipeline is considered a best practice for DevOps teams. It enables developers to deliver code changes frequently and reliably without error. The development of a CI/CD pipeline is considered an important aspect of software development across an API lifecycle, from design to management to deployment.

Continuous integration (CI) is a practice and coding philosophy intended to make it easier for development teams to prepare, implement, and run quality control on an API release. The goal of CI is to automate and ensure consistency in the building, testing, and packaging of applications. CI provides a way for development teams to integrate and validate their changes and can reduce error-prone deployment work to provide early visibility into bugs.

Continuous delivery (CD) is the other end of the CI/CD pipeline, which automates the delivery of applications and code changes, often to multiple infrastructure environments such as testing and development. CD automation can perform calls to databases, web servers, and additional services that must be updated or restarted once an application is deployed. Development teams can then use this to deploy productions on a daily, hourly, or continuous deployment schedule.

1. Prepare the release —this involves deploying an API from wherever the API is maintained, such as a Git repository, and generating a mock that will be exposed to early adopters and used by all API consumers to develop their client implementation. From the data generated from the mock, users can then compute the API versioning and status. The API is versioned according to semantic versioning; minor and patch versions are released continuously in place of the previous version.
2. Deploy the API—based on the information gleaned from the first step, an organization can publish the API in an API management solution. This declares a new service or an update to an existing one and applies the correct configuration.
3. Test an API—once business expectations are met by running acceptance tests, an organization can have API test suites stored in one place for minor releases and run tests on previous releases. To deploy the API from a CI/CD pipeline, an organization also has to publish application plans from files stored in a Git repository. Once the application plans are published, the developer has a new client application that can be used for end-to-end tests.
4. Release the API—once the tests have been done and the updates are ready, a user can deploy the new API release and publish the new documentation on the developer portal.

An API gateway is an API management tool that sits between a client and a collection of back-end services, and the API gateway acts as a reverse proxy to accept all API calls, aggregate various services, and return the appropriate result. These tend to be fully managed services that make it easier for developers to create, publish, maintain, monitor, and secure APIs at scale. API gateways support containerized and serverless workloads, as well as web applications. For organizations that follow a DevOps approach, developers use microservices to build and deploy apps in a fast-paced, iterative way. Some common functions of an API gateway include authentication, routing, rate limiting, billing, monitoring, analytics, policies, alerts, and security.

Further, an API gateway can help conduct and organize the requests being processed by the microservices architecture to create a simplified experience for a user. Further, the API gateway will route the requests to the appropriate back-end service or invoke multiple back-end services and aggregate the results. If there are failures in the back-end services, the API gateway can mask them by returning cached or default data.

Depending on an organization's approach to their APIs, API integration may be a part of their API management (whether that is through a third-party platform or not) or it may be considered a separate procedure with a separate platform; although often an API management platform will manage integrations, and an API integration platform (as a service) will often offer API management tools.

Either way, API integration is an important part of API management, especially as API integration allows users to exchange data from outside sources into an API or a back-end service, or for the various APIs across an organization to integrate data between them and increase an organization's connectivity. This can further increase or enable the flow of data between on-premise and SaaS applications, data warehouses, IoT devices, data lakes, and other endpoints in an organization's technology stack.

Further, API integration, through the organization's communication, enables the different services described above to communicate with each other often through the translation of data and information across different information standards. These translational tasks handled by API integrations further describe how an organization can increase its uniformity when it comes to data. As well, an API does not have to be associated with a single functional unit and can be resolved into various request types for different back-end systems, which in turn can communicate in different ways, requiring a multidimensional API integration to provide a unified response and, as described above, offer an organization a unified data plane.

This increased integration across an organization's various services, software, data lakes, and technology stack (including APIs) allows for a digital transformation that can maximize the use of existing data and services to overall improve efficiency and productivity, while also making the data and services more easily accessible for customers, partners, and staff.

There are two widely used architectural approaches to APIs: service-oriented architecture (SOA) and microservices architecture. SOA, the oldest of the two approaches, began as an improvement to monolithic applications, where a single monolithic application would do everything; some functions could be supplied by different apps loosely coupled through an integration pattern, like an enterprise service bus (ESB). While SOA is simpler than monolithic architecture, it carries a risk of cascading changes throughout the environment if component interactions are not clearly understood, which reintroduces some complexity and problems SOA sought to remedy.

The API lifecycle.

Microservices architecture is similar to SOA in patterns in their use of specialized, loosely coupled services. But they go further to break down traditional architectures, with services in the microservices architecture using a common language framework, such as RESTful APIs. They use these frameworks to communicate with each other without difficult data conversion transactions or additional integration layers. This allows and encourages faster delivery of new features and updates. Because each service is discrete, it can be replaced, enhanced, or dropped without affecting any other service in the architecture. This can help optimize distributed or cloud resources and can support dynamic scalability for individual services.

Example of the Twitter REST API.

API design is the process by which the "what" and the "how" of the API are formulated. This requires varying levels of thought and care that result in varying levels of API quality. A well-designed API is typified by its consistent behavior, which takes context into account and maintains the needs of users in its design. This can increase the speed of the API in which it can be learned and the likelihood of programmers making mistakes when using it. And when APIs perform similar actions, they should behave similarly, regardless of technical differences. Taking context into account also can increase consistency.

In API design, taking context into account usually means adhering to commonly accepted best practices. Knowing users and keeping their needs in mind further increase the usefulness and adoption of an API. This includes developers of an API understanding the pain points and helping users avoid that pain. In general, effective API design includes common characteristics:

• Easy to read and work with—a well-designed API should be easy to work with, and its resources and associated operations should be easy for developers working with the API to remember.
• Hard to misuse—implementing and integrating the API should be straightforward, and good design without incorrect code, offering informative feedback, and not enforcing too strict of guidelines on the API end consumer can help make the API hard to misuse.
• Complete and concise—a complete API makes it possible for developers to make applications against the data exposed; completeness happens over time with incremental builds on top of existing APIs.

To do this can include, especially with REST APIs, building atop HTTP's standards, naming resources as nouns, and incorporating popular data formats. HTTP methods are sometimes also called HTTP verbs and define the type of requests being made to the REST API. Common HTTP methods include the following:

• GET: retrieve data
• POST: add new data
• PUT: update existing data
• PATCH: update a subset of existing data
• DELETE: remove data

Resources in the API, as noted above, are sometimes referred to as the nouns that the HTTP verbs act upon. Early web services were built around remote procedure calls, where APIs were seen as an extension of the code that called upon them; whereas REST can be accessed with multiple HTTP methods. The path to access a resource, if say an API stored animals, and a user wants to retrieve a list of animals, is the pairing of the HTTP methods with the resource name:

GET/api/animals

In this schema, identifiers can be integers, hashes, or other values. Whether the resources are plural or singular can be a matter of preference, but the important part for the end user is that they remain consistent within each API and across an organization's APIs.

And in APIs, requests will return content from the server that the client needs to interpret if the data is available. This is rarely done in plain text and usually uses a structured data format. A REST API does not specify any data formats, but JSON and XML are the two most commonly used. Whichever structure (JSON, XML, CSV, HTML, YAML or RSS) is used, similar structures would be used in the body of requests when passing data, as typically request and response bodies use the same data format.

API design specifications have been around since the late 1990s. Web Service Description Language (WSDL) has been used to define web services over that time, while a more web-based approach to APIs saw the emergence of Web Application Description Language (WADL) to help describe the surface areas of APIs. And in 2011, Swagger was introduced, which offered more interactive documentation and helped developers understand what an API does and how it can be put to use. In 2015, Swagger grew to a second version. Placed in the Linux Foundation, this led to the creation of the OpenAPI Initiative to move forward the specification, and to help users and developers describe HTTP APIs. Since OpenAPI, other specifications have been developed, such as AsyncAPI.

As noted above, API specifications are more than documentation; although they are used for documentation, they are being applied across the API lifecycle. When generating documentation, they can be used to describe technical details of what an API does and publish that information to keep documentation up to date. Further, API specifications can be used to create mock-servers as part of a design-first approach to an API, and they can be used in this case for QA and testing to ensure that the API does what it needs to do and can stand up to users.

API specifications are also being used as scaffolding for testing, allowing API producers to generate contracts, integration, performance, and related tests to make sure the API is behaving as intended. API specifications can be used for security. The specification can be used to scan an APIs surface area for vulnerabilities, audit authentication, and scan for other common vulnerabilities to ensure the API is as secure as it should be. Finally, some companies use API specifications to generate client or server-side code, allowing the specification to generate code that allows an API producer to deploy the API, deploy it to a gateway, or generate SDKs in a variety of programming languages.

Scalability can be important when designing an API and related microservices. The scalability of an API becomes an essential attribute as applications continue to develop and as the use of the API becomes more demanding. This could include an increased amount of data being processed, in which scalability allows the API to adapt to the increasing amounts of data. Broadly speaking, when talking about scalability in terms of an API, this can be defined as:

• Extensible—at the most basic level, scalable APIs have to be extensible, such that the design does not limit functionality, but instead allows multiple avenues to tie into underlying services and systems.
• Built into the architecture—scalability has to be built into the foundational or architectural stages of an API, such that scalability cannot be built into an API later. Although, there are some third-party solutions to assist with later scalability.
• Demand balancing—in order to handle scalability, an API has to be able to respond to demand or handle the traffic as it comes; as it implies, this is important as scalability demands efficient performance regardless of technique or methodology and at both high and low traffic.

Similar to other software programs, low-code and hybrid low-code development has been proposed to solve the security challenges and breaches that can come with the lack of standardization in API development, often owing to a single line or two of bad code. These breaches and difficulties in code development can come at any point in the development of the API, which is where low-code development tools can offer developers a quick way to develop APIs using low-code structures that have been previously been tested. Furthermore, this allows an organization to build an API faster than traditional API development, and with fewer concerns. And the level of standardization can keep APIs consistent across an organization for internal and external users.

While low-code development platforms have increasingly included no-code features to increase the efficiency of developers, it has also been the case that, at times in low-code environments, there are integrations or use cases that are not supported. Hybrid low-code allows a developer to use low-code to speed up the development, but also to finish APIs to increase their potential use cases, integrations, scalability, security, or extensibility.

In this way, the hybrid low-code development process allows users to balance the speed of the development process with customized functionality and delivers the higher accessibility and shorter development time of the low-code environment without sacrificing the level of control of the hand-coding environment. In 2020, APIs were still largely developed by hand, but the amount of hybrid low-code tools was increasing as more companies develop or work to integrate APIs into their digitalization strategies and general workflows. Hybrid low-code and low-code can also enable organizations to integrate artificial intelligence systems into their APIs for analytics, monitoring and security, and to increase autonomous API integration.

APIs often play a role in security, as they can be used to control access to hardware devices and software functions that an application may not necessarily have permission to use. And when a user uses an API, it connects the user's device or website to the server, but neither device nor server are fully exposed to each other, which further protects both the user and the data center. Instead, each communicates with small packets of data and sharing what is necessary.

Securing APIs, or API security, is the process of protecting APIs from attacks. APIs can be primary targets because they are commonly used and enable access to sensitive software functions and data. Generally, API security is a component of web application security. The type of security can include shoring up vulnerabilities, such as broken authentication or authorization, lack of rate-limiting, and code injection. To do this, organizations will regularly test APIs to identify these vulnerabilities. And as the use of APIs continues to increase and become foundational to modern application development and use, the attack surface has expanded, increasing the importance of securing APIs.

Visualization of the attack surface of an API.

Most API implementations are either REST or SOAP. REST APIs use HTTP and support Transport Layer Security (TLS) encryption, which can keep an internet connection private and check that the data sent between two systems is encrypted and unmodified. REST APIs also use JavaScript Object Notation (JSON), a file format that makes it easier to transfer data over web browsers, meaning the APIs don't need to store or repackage data.

SOAP APIs use built-in protocols known as Web Services Security, which define a set of rules guided by confidentiality and authentication. These APIs use a combination of XML encryption, signatures, and SAML tokens to verify the authentication and authorization. Often SOAP APIs are considered to have more comprehensive security measures.

For all types and architectures of APIs, API security encompasses network security concepts such as limiting and throttling, as well as concepts from data security, identity-based security, and monitoring and analytics.

API compliance refers to regulations that API practitioners need to follow to ensure sensitive data is protected from mishandling, abuse, or loss. This can involve complying with the legal requirements from national laws, internal laws, or standards of the API industry. These can define the types of data that should be protected, the data exchange process, and penalties for failing to observe the regulations. The protected data can include users' personal information, such as a name, email, IP address, and national ID numbers.

API compliance is separate from API security, although it is often considered to be similar as they have similar goals—to minimize the security risks of APIs. However, compliance ensures that APIs follow legally stipulated data protection standards. Most of the critical API compliance risks include the following:

• Broken object level
• User- and function-level authorization
• Excessive data exposure
• Lack of resource
• Security misconfiguration
• Insufficient logging and monitoring

The main compliance standards include the GDPR, PCI-DSS, HIPAA, and ISO/IEC 27001. These compliance standards are concerned with the way personal data is dealt with in general, and across separate industries such as the payment card industry and healthcare and healthcare insurance data.

Visualization of a generic REST API.

Web service APIs are any APIs that use web service protocols and standards for exchanging data between systems or applications. Web service alone tends to support only HTTP protocol and tends to use REST, SOAP, and XML-RPC for communication. While a web service API can be used for any style of communication, supports HTTP and HTTPs protocol, and supports XML and JSON. A web service API includes features such as efficiency, wide reach, customization, personalization, data ownership, easy integration with GUI, and language-independent. The following are examples of web service APIs:

• REST (Representational state transfer)—this is a set of web API architecture principles, which means there are no official standards (unlike those with a protocol). To be a REST API (or RESTful API), the interface must adhere to certain architectural constraints. It's possible to build RESTful APIs with SOAP protocols, but these are usually viewed as competing specifications.
• SOAP (Simple Object Access Protocol)—an API protocol built with XML, enabling users to send and receive data through SMTP and HTTP. With SOAP APIs, it can be easier to share information between apps or software components that run in different environments or are written in different languages.
• XML-RPC—an API protocol that relies on a specific format of XML to transfer data, whereas SOAP uses a proprietary XML format. XML-RPC is older than SOAP, but is much simpler and uses minimum bandwidth.
• JSON-RPC—an API protocol similar to XML-RPC, as they are both remote procedure calls (RPCs), but it uses JSON instead of XML format to transfer data. Both protocols are simple. While calls may contain multiple parameters, they only expect one result.

WebSocket API is an API that makes it possible for two-way interactive communication sessions between a user's browser and a server. This API allows a user to send messages to a server and receive event-driven responses without having to poll the server for a reply. Interfaces of a WebSocket API include the WebSocket, which is the primary interface for connecting to the WebSocket server and sending and receiving data on the connection; CloseEvent, which is the event sent by the WebSocket object when the connection closes; and MessageEvent, which is the event sent by the WebSocket object when a message is received from the server.

Library-based APIs allow a running code to talk with another running code. Since a library tends to refer to a chunk of running codes that are designed to be reused during development, an API is the method or means by which these running codes interact with each other. While an API can be thought of as the logical representation of what is in the library, or the consistent format that explains what can be done with the library. Common library-based APIs include:

• Javascript
• TWAIN

Class-based APIs work to support class-based views, where a view is a callable, which takes a request and returns a response over an HTTP protocol. In the case of a book library, the API client would connect and download book data for books published since last visit. Examples of class-based APIs include:

• Java API
• Android API

OS functions and routines APIs are any API used for OS functions, such as documented, callable subroutines in an OS API, such as processes including CreateProcess, CreateFile, and GetMessage in the Windows OS through the Window API. Other functions of these APIs include:

• Access to file system
• Access to user interface

Object remoting APIs allow for an instantiating of an object in another process, or even on another machine, and interacting with that object as if it were an ordinary, in-process object instance. These APIs, especially .NET framework APIs, tend to be legacy APIs. And in the case of many .NET APIs, Microsoft has begun phasing out their services in favor of WCF or HTTP-based REST services, which can communicate with objects in other applications or across machines. Some object remoting API examples include:

• .NET Remoting
• COBRA

Hardware APIs, also known as Hardware Platform Interface (HPI), are an open specification that defines an API for platform management of computer systems. These APIs support tasks such as reading temperature and voltage sensors, configuring hardware registers, accessing system inventory information, and more complex activities. These are used with fault-tolerant and modular high-availability computer systems, which typically include automatic fault detection features and hardware redundancy. Some hardware APIs include:

• Phillips Hue
• Google PowerMeter
• WareNet CheckWare

Event streams help software extend beyond the request-response approach common to web API styles (such as REST or GraphQL). This allows the software to communicate bi-directionally, removing the need for API consumers to poll for state changes and instead allowing APIs to publish events to an event stream for notification of data changes or important business events to any number of subscribed services for processing. Streaming and event APIs are able, in this way, to provide high performance and a reliable mechanism for streaming significant amounts of data on a constant basis. Common examples of streaming and event APIs include:

• Twitter API
• Salesforce API

A healthcare API is any API built to allow for easy and standardized data exchange between healthcare applications and related solutions, often with support for popular healthcare data standards such as HL7 FHIR, HL7 v2, and DICOM. This can allow for the building of fully managed, highly scalable, enterprise-grade development for building clinical and analytics solutions and can include value-added capabilities, such as de-identification for better data preparation and analytics and machine learning capabilities for better data streaming. Use cases for APIs across healthcare include:

• EHR APIs
• Consolidated APIs to access patient data
• Clinical data management and analytics APIs
• Public health content APIs
• Drug data and drug interaction checking APIs
• Symptom checker APIs
• Telehealth APIs

Retail APIs allow for multiple different retail services to be built into a retail service endpoint, such as personalized recommendation systems, catalog and product search, order submissions, inventory, and specific retail solutions for specific business lines. This can allow a retailer to provide a digital channel experience as efficient and well-rounded as a brick-and-mortar experience and further allows for the integration of newer services to the digital channel as they are developed. APIs and a digital channel can also allow retailers to reach a wider audience, offer affiliate services, and allow customers to query an entire product base. Examples of retail APIs include:

• ASOS API
• H&M API
• Adidas API
• Google Shopping API
• Barcode Lookup API
• Amazon-Price API
• Feeditem-eBay API

Open banking API refers to the practice of traditional or incumbent banking institutions opening their APIs to third parties to allow those third parties to develop new applications and services. This offers the traditional banks and the financial technology companies a chance to cooperate rather than compete. Under the system, a bank allows third parties to access the necessary financial information required for financial technology companies to develop those new applications and services, which further provides account holders greater financial transparency and greater financial experiences. As well, this places greater pressure on incumbents to improve their offerings, cultivating cooperation and competition in the banking industry to the benefit of the account holder. There are a variety of benefits from an open banking API for both traditional financial institutions and financial technology companies:

• Faster innovation
• Increased revenue
• Detailed customer insights
• Personalized offers

Examples of open banking APIs include:

• BBVA—in 2018, BBVA launched a BaaS platform - Open Platform - which utilized APIs open to third parties to offer customers financial products without needing to provide the full suite of banking services.
• HSBC—In 2018, the bank launched its Connected Money application in response to the UK's open banking regulations, which allowed customers to view various bank accounts, loans, mortgages, and credit cards in a single application.
• Barclays—Barclays opened a mobile banking application that allowed account aggregation inside a single mobile application, offering customers views of their disparate accounts within the Barclays' mobile application.

AI and machine learning APIs are services that provide a set of functions and procedures for developers to use. Often these are statistical techniques that bring about a perception of learning in the programs in which these APIs are used. This can help a program solve a specific problem in a specific project, or can be used to provide data-matching and pattern-matching capabilities to develop results. Examples of AI and machine learning APIs include:

• AmazonML API
• Aylien Text Analysis API
• Microsoft Azure Machine Learning API
• Google Cloud Machine Learning API
• IBMWatsonSTT API
• Kairos API

At the core of all IoT devices and their ability to connect to the internet for communication and conducting their allotted operations are APIs. Communication APIs especially play an important role in IoT, as often computing is done off-device, and the communication API empowers the IoT devices for information exchange, including the bulk of computing and data retrieval to be done in the cloud. Examples of APIs for the IoT include:

• Garmin Health API
• Google Assistant API
• Withings API
• Tesla Model S JSON API
• Apple HomeKit

With the increasing use of blockchain and decentralized applications, the APIs used in blockchain have also increased in use. The APIs used in blockchain are similar to the APIs used in other web services and software services. They offer communication between blockchain services; security and authentication services to increase the trustless nature of blockchain services; a way to offer distributed processing and deliver token-based computation; a system for ownership and collaboration within data environments; a system of dynamic management of blockchains and helping those blockchains to log transactions to specific users, specific times, and specific environments; improvement of blockchains by monitoring and tracking them to identify inefficient nodes and areas of issue; and APIs can be used to unify and integrate disparate blockchains and blockchain environments and increase interoperability between environments. Blockchain API providers include:

• NOWNodes
• Coinbase
• Bitcore
• ICObench Data API
• Web3.js Ethereum API
• Infura Ethereum API

APIs are seeing increasing use in the automotive world, as they offer vehicle applications to interact with other applications or software platforms. This could include an advanced driver-assistance system that could make APIs available to perform specific functions, allowing them to retrieve information about the current environment to better inform the driver-assistance system's decision-making on that information. This could be especially important in the case of a hands-free or autonomous driving vehicle, where the API would allow the vehicle and driver to access information about the vehicle and what the vehicle sensors are seeing in the surrounding environment, which could further build trust in the system's performance. Examples of automotive APIs include:

• Vin Decoder
• CIS Automotive
• CarsXE
• Live Parking
• Carma
• Edmunds
• Smartcar

As APIs see increased use in various industries, they have also begun to be used in cybersecurity programs. Here, APIs are used to detect and clean malware and viruses, explore the reputation of websites, explore an attack surface area, conduct cyber fraud investigations, monitor brands, search for copyright violations, and run bug and data bounty programs. Examples of security APIs include:

• Google Safe Browsing API
• PhishTank API
• VirusTotal API
• Quttera API
• Sucuri API
• GreyNoise API
• URLScan API

Popular social networks offer service APIs to devoted users, which offer developers a chance to expand the reach of their applications. Social media APIs can allow developers to display content on any application, such as tweets, Facebook posts, or photos from photo-sharing applications, and make them visible to end-users. These can work for primary content and related details and are used to display everything from users' posts to photo metadata and locations. These APIs allow users to put content into a related service. Some social media APIs include:

• Twitter API
• Facebook API
• Instagram API
• YouTube API
• Reddit API
• Pinterest API

In the travel industry, APIs are being used more as companies are increasingly open to sharing data with each other, creating ways for consumers to interact with various tools and systems through a single platform to help unify the experience and simplify the experience for the average traveler. This again works best through connectivity and communication, which APIs offer between applications, which can in turn power flight search and booking platforms; hotel booking aggregators; flight data, schedules, and fares; wholesale hotel booking with bed banks; partner hotel booking with OTAs; hotel mapping; car rental booking; business travel management and expense tracking; tours, attractions, and experiences; and reviews and ratings. Some travel APIs include:

• Skyscanner Flight Search API
• Amadeus Trip Purpose Prediction API
• Hotels.com API
• TripAdvisor API
• webcams.travel API
• IATA and ICAO Codes API

Entertainment APIs span a variety of topics but work to connect a user's application to a respective database for the necessary or desired information. For example, the IMDB application uses an API to return information about movies, television shows, actors, or directors to a user's phone. For developers, an API allows them to connect applications to massive databases and offer the data from these databases to their platforms and their users, based on their parameters. These APIs can be used by movie theaters, web administrators, and independent musicians, and they provide users with various amounts of information, such as song lyrics, movie facts, or actor information, or can include simple jokes, game content, or other consumable internet media. Examples of entertainment APIs include:

• Imgur
• uNoGS
• Movie Database Alternative
• HAPI Books
• MDBList
• YouTube to Mp4
• Meme Generator