API Simplified

API (Application Programming Interface) are a central concept in software development, and have taken on even greater significance in the changing landscape of cloud development.

Every piece of code functionality exists in a web of dependencies; that is, other functionality upon which it depends.

API are the doorways through which code reaches out to those dependencies.

API define the set of available commands to otherwise hidden functionality

Two Kinds of API

How programmers love to overload terms. In general, an API is any mechanism through which a code block makes a call to another code context.

But in actual fact, there are two kinds of API:

1. Local API: This is the calls we make from code-to-code via language level calls
2. Remote API: A call made via network to a hosted service

In both cases, the following diagram applies. This is the basic function of API.

Local API

These have long been central to programming. Any time a call is made to another code context (another Object or Function), a Local API is being invoked.

On the flip side of that coin, any time we are writing code, we are defining an API for the current code context.

Remote API

There are a variety of RPC (Remote Procedure Calls) where a local API call as described above is mapped to a remote host, however, the kind of remote API that are most significant to the cloud are built on top of HTTP.

These have shaken out over time into two primary layers on top of HTTP:

• SOAP
• REST

In both cases, these "specifications" (I use the term loosely here) define what operations are available to callers, and what kind of data is exchanged.

There is nothing really magical about these things: they are simply a way to either formally (SOAP) or less formally (REST) define what interactions are available at a network location.

The API Ideal

The primary advantage of a remote API is that it allows for language agnostic usage, and seamless deployment and update.

The chief factor to consider when designing any API is encapsulating the functionality it wraps in a way that is as simple to use as possible, and reveals as little of the internal workings as possible.

So in short, by hosting API at a network location you achieve complete isolation between client and service.

Network API Drawbacks

Nevertheless, network API have drawbacks, primarily these kinds:

1. Performance: Latency over the wire for calls
2. Security: Exposure of API to the network; endpoint security
3. Manageability: Increase of complexity in providing infrastructure (network and host); increase of complexity in understanding and addressing relationship of application components

Architecture of the Middle Way

The perfect balance between local and remote API surfaces is a per-application affair. In general, the current push is toward microservices whereby the application is split into smaller discreet components available on network API.

This is a natural outgrowth (in fact, is really the same thing) as SOA (Service Oriented Arhcitecture).

Where's it Headed?

I don't see a future where the unit of execution becomes tinier and tinier, until the cloud is a network of isolated and highly specialized API surfaces. I believe that internal design and API usage will remain with us.

The key is to balance local and remote API usage.

I don't think we'll ever see a time where you want to call a remote service to obtain splitString() or the like.

Do you?