API for the Curious - Part 2 - Evolution

In the first article of this series, we discussed about a formal definition of API. In this article, we are going to investigate the history of API.

Beginning

The concept of API is nothing new. When we code, you will notice that there are many codes that are redundant, that can be created as a function and can be reused. We can consider this as the beginning of the concept of API. A function will have defined rules of how it can be invoked. What parameters need to be passed and what is the expected result. But this is limited to calls withing the programs than a program residing on a network calling through some protocol to call another program residing in another computer. For example, look at the example code below, written in COBOL (I am using COBOL to show you that even in COBOL, this concept was there). The first program, NSQUARE is a subroutine which gives square (LS-NUMBER-SQUARE) of a given number (LS-NUMBER-1) and is called by the MAIN program. A similar example in Python is also shown in Fig.3

IDENTIFICATION DIVISION

PROGRAM-ID. NSQUARE.

?

DATA DIVISION.

?? LINKAGE SECTION.

?? 01 LS-NUMBER-1 PIC 9(4).

?? 01 LS-NUMBER-SQUARE PIC 9(15).

?

PROCEDURE DIVISION USING LS-NUMBER-1, LS-NUMBER-SQUARE.

?? MULTIPLY LS-NUMBER-1 BY LS-NUMBER-1 GIVING LS-NUMBER-SQUARE.

EXIT PROGRAM.
        

Fig. 1 COBOL Subroutine

IDENTIFICATION DIVISION

PROGRAM-ID. MAIN.

?

DATA DIVISION.

?? WORKING-STORAGE SECTION.

?? 01 WS-NUMBER-1 PIC 9(4) VALUE 10.

?? 01 WS-NUMBER-SQUARE PIC 9(15).

?

PROCEDURE DIVISION.

?? CALL 'NSQUARE' USING WS-NUMBER-1, WS-NUMBER-SQUARE.

?? DISPLAY 'NUMBER-1: ' WS-NUMBER-1

?? DISPLAY 'NUMBER-SQUARE : ' WS-NUMBER-SQUARE

STOP RUN..        

Fig 2. COBOL Main program calling the subroutine

def square(num):
? ? return num*num


square(5)        

Fig 3. Python example

As you can see, we can use the subroutine NSQUARE to get the square of a number by passing number to be squared in the variable, WS-NUMBER-1. This is very common in most of the programming languages. The NSQUARE has an interface where you can pass the number to be squared and get back the square of the number in another variable. So, this qualifies in certain way, our formal definition of API.

But, in this case, the usage is limited to the same computer where the subroutine and the main program resides. The call is local to the computer where the main program resides and is called as Local Procedure Call (LPC).

90's

As time progressed, many advancements happened in computer science. In the '90s client-server architecture became predominant. This technology allowed programs residing on client machine to communicate with databases residing on remote servers. Though this is mostly limited to Database systems residing on a server, data can be accessed remotely. We can call this as an example of Remote Procedure Call (RPC).

With the invent of Internet, accessing information residing on computers anywhere in the world became very easy. Internet became the ultimate client-server system. Exchanging valuable data in a predictable way among business partners through internet has become the next frontier of advancement. SOAP which is based on XML popped up in late '90s. This can be considered as the predecessor for modern APIs.

Modern Times

Few things happened in the 2000's that led to the evolvement of the modern API. First, Roy Fielding at UC Berkley published a paper that led to the development of REST. In 2002, JSON format was introduced as an alternative to XML. Apple introduced iPhone in 2004 and suddenly mobile devices became the major consumer device.

Though, SOAP was picking up as a mechanism to share data between systems, it has many disadvantages that halted its popularity.

1. Very complicated standards that is challenging to understand. So, this is not something developers liked much, but, adopted probably because there were no other choices at that time.
2. The standards changed regularly and keeping up became very difficult
3. The payload size or data size was large due to XML and the standards the message adhered to and hence required high bandwidth.

Meanwhile, the introduction of iPhone and subsequent introduction of other mobile devices created an app ecosystem. The apps required to communicate remote servers to provide the data and this data was rendered on the client side to provide the UI (User Interface). Initially, XML was used as a format from server side to send data. But developers soon realized that XML parsing is very CPU intensive and drains the battery of the mobile devices quickly. So, the users were not very happy. This is what led to the popularity of JSON instead of XML for data exchange between apps and servers.

Meanwhile, REST paper described how basic CRUD operations on data can be done using HTTP verbs. This led to the simplification of how resources (data) which is residing on servers can be accessed in a very simple standardized way.

Present State

The advancements in data structures and protocols led to the current state of APIs. For accessing data remotely, REST and JSON have become the de-facto standard. APIs built using REST architectural style is known as REST API and that on HTTP protocol is known as HTTP REST API. We will be digging more into REST and JSON in later articles.

JSON and REST has become de-facto standards for modern API development

Summary

• API is not a very new concept, it evolved over a period of time to reach the present state
• SOAP became a standard in early 2000's, but lost traction towards the end of 2000's.
• Where SOAP left of, REST and JSON became de-facto standard for API development at present times.

Note: Please share your comments to improve this article. Please point out any mistakes, so that all readers can benefit out of it. If you like this article, please share it with others, who will get the benefit of knowledge because of your action.

#api?#apis?#apimanagement?#apifirst?#apidevelopment?#apidesign?#apideveloper?#apieconomy?#apiintegration