HTTP & REST #

In a nutshell, an API is just a set of rules (protocol). Any two software systems that agree on the protocol can start to "talk" to one another. The protocol allows two software systems to be linked regardless of differences in their internal processes, structure, or design. The most common protocol for building APIs is HTTP.

Hypertext Transfer Protocol #

HTTP stands for Hypertext Transfer Protocol. It owes its popularity to the ubiquity of web applications and its simplicity and ease of use. HTTP is the foundation of any data exchange on the Web. At its core, it functions as a request-response protocol in the client-server computing model.

For example, to visit a website, you enter its URL in a browser application. The browser sends a request to fetch the HTML document that represents the landing page of the website. The browser in this scenario is the client. It sends its request in HTTP. The request travels from your computer to your modem/router and then through the internet until it reaches a server. A server appears as only a single machine virtually. Still, it may be a collection of computers, sharing the load (load balancing), or a complex piece of software interrogating other computers. The server processes the request, retrieves the requested resource, performs the necessary actions, and sends the response to your browser in HTTP. The browser then interprets the response data and presents you with the web page you want.

Representational State Transfer #

A common practice to separate the client and server is Representational State Transfer, or REST architecture style.

In this style, the implementation of the client and the server are done independently without each knowing about the other. Therefore, the client-side or server-side code can be changed at any time without affecting the other side.

It is said that RESTful systems are stateless. In the Client-Server architecture, stateless means the server does not need to know anything about the client's state and vice versa.

HTTP fits well with the REST style: the client and the server communicate by sending "messages." The statelessness of REST means the server and the client must understand any message received without seeing previous messages.

Implementing RESTful (or simply REST) APIs using HTTP is so common that people mistakenly think HTTP and REST are the same things.^[1]

Alternatives to REST include GraphQL, gRPC, and Apache Thrift. Alternatives to HTTP include FTP, SFTP, and WebSocket.