API - Whats and hows?

API is an acronym for an Application programming interface. In simple terms a software intermediary that helps two applications talk to each other. The most common example in day-to-day life is when you are using the weather app or a messaging app.?

Each time you use the application, the application will need to connect to the internet and send the request to the server, the server then retrieves the request data, interprets it, perform necessary actions and then send the response back to the application which in turn interprets the data and presents the information in a human-readable format.

What API does differently is by providing a layer of security so that your device data is never fully exposed to the server and the server is never fully exposed to the device. The communication is usually with small packets of data sharing only what is necessary.

There are many types of APIs including program centric APIs like Java API that lets objects talk to each other, web APIs including Simple Object Access Protocol (SOAP) which was one of the most popular enterprise formats for API until the emergence of JSON which brought more reliance on HTTP and JSON Remote Procedure Call (RPC) and the current de facto standard Representation State Transfer (REST).

How are these different from each other? The table below provides a summary of the strengths and weaknesses that each of these APIs possesses.

Table 1.0

REST being the most popular, let's try to understand REST a bit more

REST is a software architectural style that satisfies constraints asserted by Dr. Roy Fielding in his dissertation ( Chapter 5). ?RESTful is typically used to refer to web services implementing such an architecture.

There a six key constraints to REST

1. Client-Server: the client and the server should be separate from each other and allowed to evolve letting the client and server grow and scale independently.
2. Stateless: The call can be made independently of one another, and each call contains all of the data necessary to complete itself successfully.
3. Cache: REST API must be designed to encourage the storage of cacheable data. In simple terms what this means is the response should indicate that the data can be stored up to a certain time (expires in some duration), or in cases where data needs to be real-time, that the response should not be cached by the client.
4. Uniform Interface: The uniform interface lets the client talk to the server in a single language, independent of the architectural backend of either.?
5. Layered System: layered system style allows an architecture to be composed of hierarchical layers by constraining component behavior such that each component cannot "see" beyond the immediate layer with which they are interacting.?
6. Code-on-demand: This is an optional constraint, which allows client functionality to be extended by downloading and executing code in the form of applets or scripts. This simplifies clients by reducing the number of features required to be pre-implemented. Allowing features to be downloaded after deployment improves system extensibility. However, it also reduces visibility.

Let's now see some of the API buzzwords and what they actually mean

Realtime API: Any API designed such that data flowing from producers to consumers happens in the shortest amount of time possible can be described as real-time. This however this doesn't mean that the response will always be returned in split seconds but within the shortest span, the query is processed.

Realtime is about pushing data as fast as possible and is automated, synchronous, and bi-directional communication between endpoints at a speed within a few hundred milliseconds (ref: realtimeapi.io).?

Synchronous API: Synchronous API calls are those that are processed one after another and you can make the next call only after the previous API call is returned. End-users usually see this to be a latency or performance lag in your app, that is why asynchronous requests are typically more preferable.

Though real-time APIs are synchronous, it's not the other way round. The Synchronous API may not be real-time.

Asynchronous API: Asynchronous calls do not wait for a response from the server to proceed with further calls. In the case of asynchronous APIs, the availability of a resource, service, or?data store?may not be immediate. These APIs may provide a callback to the requester when the requested resource is ready.?

API pricing

API call quotas are used for defining the pricing plans by their providers. API call quotas refer to a limited number of HTTP pull requests that can be made to the API endpoint.?

On contrary, API call rates?define API bandwidth, which depends on the number of asynchronous calls that can be performed per time span to the API endpoint. It means that if you’re allowed to make up to 10 requests per second, the API endpoint will take 10 parallel requests every second and process them asynchronously.

API quotas and call rates are different tools used by API providers to control server loads and set prices for users. API call rates play a very important role because having access to a high bandwidth means the capability to deal with higher traffic and request loads.

References:

• Roy Fielding, Architectural Styles and the Design of Network-based Software Architectures
• Michael Stowe, Undisturbed REST