What is an API?

A 1969 NASA publication entitled Computer Program Abstracts contains a summary of a real-time display control program sold by IBM (only $310! Plus $36 if you want the documentation). The advertisement says that this program was designed as an operator-application programming interface – in other words, an API. Application Programming Interfaces (APIs) have been around for about as long as computer code has. Conceptually, it is just a way for two different pieces of code (or a human and some code) to
interface with each other. A class that provides certain public methods that other code can call has an API. A script that accepts certain kinds of input has an API. A driver on your computer that requires programs to call it in a certain way has an API. However, as the internet grew, the term API narrowed in focus. Almost always now, when someone talks about an API, they are talking about a web API.

A web API takes the concept of an interface between two things and applies it to the client/server relationship that the internet is built on. In a web API, a client is on one side of the interface and sends requests, while a server (or servers) is on the other side of the interface and responds to the request.Over time, the internet has changed and evolved, and web APIs have changed and evolved along with it. Many early web APIs were built for corporate use cases, with strict rules in place as to how the two sides of the interface could interact with each other.

A type of API called the Simple Object Access Protocol (SOAP) was developed for this purpose. However, in the early 2000s, the
web started to shift toward becoming a more consumer-based place. Some of the e-commerce sites, such as eBay and Amazon, started to publish APIs that were more public and flexible. This was followed by many social media sites, including Twitter, Facebook, and others. Many of these
APIs were built using a pattern called Representational State Transfer (REST). This approach is more flexible than SOAP and is built directly on the underlying protocols of the internet.

The internet continued to change though, and as mobile applications and sites grew in popularity, so did the importance of APIs. Some companies faced challenges with the amount of data they wanted to transfer on mobile devices, so Facebook created yet another type of API called GraphQL. This type of API defines a query language that helps to reduce the amount of data that gets transferred, while also introducing a slightly more rigid structure to the API. Each of these different API types works well in some scenarios.

Types of API calls
Some calls to APIs can change things on the server, while others return data without changing anything. The terms **safe and idempotent **are used to describe the different ways that API calls can affect data. These terms might sound a bit intimidating, so in order to better understand them,
let’s look at an illustration that uses something we can all understand: LEGO pieces.

Imagine that there is a table with a couple of LEGO pieces on it and I’m sitting by the table. I represent an API, while the table represents a server, and the LEGO pieces represent objects. If you come along and want to interact with the LEGO, you must do so through me. In this illustration, the LEGO pieces represent objects on a server, I represent an API, and you represent a client. In picture form, it looks something like this:

You are going to be the client in this imaginary relationship. This means you can ask me to do things with the LEGO. You ask me to tell you what size the top LEGO piece is. I reply that it has a size of one. This is an example of an API request and response that is safe. A safe request is one
that does not change anything on the server. By asking me for information about what is going on in the server, you have not changed anything on the server itself.

There are other kinds of API calls though, well explained in the book API Testing and Development with Postman by Dave Westerveld.