In general, APIs can be defined as providing a standard and common access interface for an application and database; to other software developers and applications, providing certain data (and meta-data), or services, without these other external parties needing to worry about the inner logic of the provided service.
An API is in simple terms a menu of items you can use or choose from. When you buy a product online, you are unaware of how it is stored, removed from inventory, packaged, and delivered. You simply call these functions when you place the order.
Public Cloud is a natural fit for the API computing paradigm. Application developers may use APIs to access Cloud services through web-based communications for example, or a developer will produce code which makes a call to the Cloud provider’s API, passes the requisite parameters and arguments in the context of that call (JSON, XML), and then examines the response to confirm the operation.
A Cloud API enables end users to access a Cloud provider’s application or service, including IaaS, PaaS, storage, monitoring, reporting tools. Cloud APIs will present a defined set of features and functions for that application or database service, along with the details or functions to execute them. Many APIs are built on RESTful interfaces (Representational State Transfer), using SOA (simple object access) protocols, JSON payloads and authorisation security protocols such as OAuth 2.0.
Within the Public Cloud, APIs are central to the on-demand usage of functionality. AWS, Microsoft Azure, Google Cloud Platform and other Public Clouds use APIs to enable all end-user access and functionality. They also allow software vendors to ‘plug-in’ their services into the Public Cloud platform. SaaS vendors are also important enablers of APIs, using Cloud APIs to integrate their products with third parties, and extending their platforms to encompass other functionality. An example is the Salesforce market-place or the SurveyMonkey Cloud API which can be embedded in a third party application.
AWS is built along APIs which connect all of their key internal service offerings. For example AWS EC2 compute has APIs which integrate with EBS (elastic block store), VPC (virtual private cloud), and VPN (virtual private network). The S3 object store provides an API which supports S3 integration with various services as well. Every time we use these services, we are using an underlying API.
For example, if I want to deploy a few EC2 instances using a specific AMI (application machine image), in a certain region, the underlying script command, wrapped in an API, may look like: https://ec2.amazonaws.com/?Action=RunInstances&ImageId=ami-60a54010&MaxCount=3&MinCount=1&Placement.AvailabilityZone=EU-central-1b&Monitoring.Enabled=true&AUTHPARAMS
The main API command is ‘RunInstances’ with the parameters to contain ‘ImageID, Max Count, Min Count, Placement, AZ, Monitoring’. The details for each of these parameters is called the parameter “arguments”. There may indeed be hundreds of commands with the invocation of the parameter arguments. The AWS EC2 API manual is many hundreds of pages long, outlining all command details.
If you are building or providing a service or application, the API will maintain access, control and security of your data. You can also track API usage and build a revenue model from understanding where your API is being used and charge accordingly for each API call.
If for instance I have built a Cloud application that is using geographical data (example, how far did I run, or cycle?), we could utilise a Cloud service such as Google Maps to provide visual mapping and location tracking, and then estimate from that distance, pace and time, the calories used, health impact and input that event into a historical database for the end user to compare performance over time. By using the Google API we don’t need to build our own maps or algorithms calculating distance. Of course, it is not free. Social media is another example of platforms providing APIs to allow outside developers to access services and data.
Cloud APIs resolve a critical issue: connection. APIs will connect software applications across heterogenous networks. 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. This is critical since APIs are usually built to provide a service across multiple applications, with on-demand users. In AWS simple examples would include using a storage service, or a serverless function provided by Lambda.
APIs also resolve the problem of integrating distributed components. Application components will ‘call’ each other’s interface (API) allowing the underlying components to be updated or changed, without affecting the using application. This is also the publish-subscribe model. We can build an API which ‘subscribes’ to a publisher component but is unaware of the details or arguments of that publisher’s interface. Micro-services would be an example of loosely coupled API integration with each container’s details separated within the architecture, and any updates to that container do not affect other containers or their applications.
Business applications may also share an API. Several database deployments may use the same API for database access. This is a common pattern for larger systems based on shared inventory, or product information. Usually, however, APIs are built for an application or database service and are initially ‘unique’ to that business. An API built to satisfy the requirements of one business, may not be appropriate for another business. Within Cloud for example, this could include lock-in, as we deploy more virtual machines or containers onto EC2, it makes it difficult to move those VMs easily given API and other integration (scripts, security, patching), to another platform.
