APIs are a common way for software developers to interface with services, without worrying about the inner workings of that service or the service provider.

While cloud users can employ consoles and portals to provision and control cloud resources, the public cloud is also a natural fit for APIs. Application developers use APIs to access cloud services through web-based communication. A developer writes code that makes a call to the cloud provider's API, passes the requisite parameters and arguments in the context of the call, and then examines the response to confirm the operation. Let's take a closer look at the purpose and use of APIs in cloud computing.

A cloud API enables end users to access a cloud provider's application or service, such as compute infrastructure, storage resources or monitoring tools. APIs define the possible features and functions of that app or service, along with the details needed to execute them. APIs are typically based on REST or Simple Object Access Protocol communication schemes and rely on authorization schemes such as OAuth 2.0 to ensure user authentication and security.

Think of an API as a menu for a restaurant. A menu, or an API, is an interface you use to decide what to order. To order, you don't need extensive insight into how the restaurant, or service provider, operates behind the scenes.

Public clouds are founded on the notion of self-service and automation, so APIs are critical to how they operate. In fact, AWS, Microsoft Azure, Google Cloud Platform and other cloud platforms use APIs to drive all of their user-facing operations, such as when developers create new software or when they use the console. Let's consider how this works with AWS as an example.

AWS provides a broad range of APIs that can drive any provisioning or operation. For example, the Amazon EC2 API supports services that include Amazon EC2 instances, Amazon Elastic Block Store, Amazon Virtual Private Cloud and AWS VPN. The Amazon S3 REST API supports Amazon S3.

Suppose a software developer wants to use AWS to create up to three EC2 instances using an Amazon machine image called ami-60a54010. The developer also wants to locate those instances in an Availability Zone in the US East-1 Region, and enable monitoring of those provisioned compute instances. The EC2 API command might appear as:

https://ec2.amazonaws.com/?Action=RunInstances&ImageId=ami-60a54010&MaxCount=3&MinCount=1&Placement.AvailabilityZone=us-east-1b&Monitoring.Enabled=true&AUTHPARAMS

As shown above, the fundamental API command is RunInstances, while parameters include ImageId, MaxCount, MinCount, Placement.AvailabilityZone and Monitoring.Enabled. The details for each parameter are the arguments of the parameters. There can be hundreds of API commands. The Amazon EC2 API reference manual alone consists of hundreds of pages of documentation.

Developers can build powerful applications faster than ever with APIs. For service providers, the API maintains their control and security of the data. Providers can also track API usage, which makes it a valuable and growing source of revenue. Every time a developer uses a provider's API, chances are they're paying something for that call -- or per-thousand calls or whatever the case may be.

For example, software designed to process and render geographical data might employ a cloud service such as Google Maps to provide visual mapping and location capabilities. This alleviates the need for a business to create its own maps and mapping algorithms, but it isn't necessarily free either. Other major platforms such as Facebook, Twitter, Netflix and countless other providers have APIs that allow outside developers to access services and data.

The single, overarching issue APIs address is connection. APIs connect software across a network. When a business creates an application or a service, an API can be created and deployed to allow other software to interface with that software or service.

APIs are typically designed and implemented when a service is used by multiple applications and many users want to access the same service. This is ideal for the public cloud, where countless users might access a service such as AWS Lambda or transfer data to a storage service.

APIs are also well-suited for applications that are implemented as multiple distributed components. The application components call upon each other's API(s). In this way, the components can be updated and scaled independently and located in distributed locations for greater performance and availability. One example of this is container-based microservices applications that rely on APIs for container-to-container communication.

Different applications within a business can share the same API. For example, several database deployments may use the same API for database access. However, APIs are typically unique and purpose-built software that is rarely standardized between businesses and developers. The API developed by one business to support one application will almost certainly not work for another application developed by another business. This approach underlies many of the issues around cloud provider APIs, vendor lock-in and cloud API standardization.

There are several ways to categorize APIs. One popular way is to distinguish between vendor-specific APIs and cross-platform APIs. A vendor-specific cloud API is intended to support the services of a particular cloud provider. For example, the Microsoft Azure REST API is dedicated to the many services offered by the Azure public cloud, such as Azure DevOps, Cosmos DB and Visual Studio. A vendor-specific cloud API can be developed to address every nuance and feature of that platform. However, it will only work with that provider, and you'll need a different API to work with other providers.

By comparison, a cross-platform API is intended to provide identical functionality between two or more cloud providers. Examples of cross-platform APIs include Simple Cloud, part of the Zend Technologies, Apache's jclouds, and Apache's Libcloud. Developers can employ the same commands and parameters to perform the same tasks regardless of the actual cloud provider. However, this often leads to limited functionality and control, which is why vendor-specific APIs remain the most popular type of API for developers.

Cloud APIs can also be categorized by type, such as infrastructure, platform and software. IaaS APIs are typically focused on provisioning compute and storage resources. PaaS APIs are generally dedicated to providing back-end services or architectures such as databases. And SaaS, or application, APIs are intended to provide connectivity or interoperability with a software product or suite, such as Microsoft Office 365.

Application portability is a central concept of modern cloud computing and a solution to vendor lock-in. Cloud users may want to relocate data to another provider's services if they have better capabilities or lower prices. For example, a business may opt to move a data set to another cloud if it offers better machine learning and AI services.

APIs handle the actual dynamics of executing the migration. APIs create and secure a target storage resource in a desired cloud region and then implement the copy process. Such processes can typically be performed programmatically through a script. The actions executed by such a program would invariably interface with the source and destination cloud providers through their respective APIs, because everything in the public cloud happens through APIs anyway.

But there are cloud services intended to accelerate cloud data migration, such as the AWS Transfer Family or Google's Transfer Service for cloud data. Such services can simplify the migration process, though the services will still employ cloud provider APIs.

Ultimately, data migrations require the use of APIs and involve a clear business strategy and significant planning to understand the business tradeoffs, performance impacts, and cloud data movement and storage costs involved with any cloud data migration.

Standards are attractive because any product or service that adheres to them will behave in a known, well-understood manner. Cloud standards are central to the ideas of cloud interoperability and portability. Thus, cloud API standards make it easier for organizations to use multiple clouds.

However, standards are often more of a negotiation than a technical hurtle. As with any service, it's the differentiators -- the features and capabilities only available with a certain provider -- that make a public cloud service stand out. If every provider offered the same set of services in the same way, competitive differentiators would be lost. Similarly, standardization demands some sharing of intellectual property, which would be a bitter pill for providers to swallow, given the investments they've made in their platforms.

Progress toward any common cloud APIs has been incredibly slow because the public cloud market is owned by three principal providers -- AWS, Microsoft and Google. Standardization is only economically attractive when there are many competing providers and the industry would suffer or adoption would falter without it. This isn't really the case in today's public cloud market.

There are some standards initiatives evolving quietly, such as the cross-platform cloud APIs noted earlier. However, cloud providers are more likely to adopt industry standards that drive greater usage or make it easier to deploy applications on their platforms. For example, adopting a prevalent technology standard such as Open Virtualization Format (OVF) makes it easier for cloud users to create machine images that are suitable for rapid, scalable cloud deployment. For example, the machine image file name used as the argument to an API parameter would usually be an .ovf file, though other common formats can also be supported.

In other cases, cloud APIs will seek to support critical behaviors such as security and authentication standards, including HIPAA, Payment Card Industry Data Security Standard, Federal Risk and Authorization Management Program and many others. Organizations that operate in those industries will be better able to adopt a public cloud infrastructure if those platforms adhere to regulatory standards.

More here:

An FAQ on cloud APIs and application development - TechTarget