API Request Response Lifecycle: A Stupid Simple Explanation

Photo by Dean's Photo on Unsplash

TLDR: APIs facilitate a request-response lifecycle where clients send requests with actions and servers return data or confirmations. REST APIs use CRUD operations (GET, POST, PUT, DELETE) with URLs to manage data. Understanding this process simplifies software development.

Software engineering isn’t complicated. Sure, terms like blockchain, middleware, or proxy server may seem foreign to most people. However, when you understand that they are just Lego pieces you use to build what you want, software development gets less scary.

APIs or application program interfaces are another one of these terms. They seem complicated but can be reframed as a concept like house addresses. You want to go somewhere to do an activity. As long as you have the address of where you want to go, you can make it there. The key part of the API I want to demystify is the request-response lifecycle.

A super simple explanation

What is a request-response lifecycle? This term is the process of someone asking for something and (hopefully) getting it. You have a request you make to someone or something and you get a response of something or confirmation that some task has been completed.

Figure 1. Basic Request-Response interaction.

This is how APIs work. You have a specific someone or something you send a request to. This request includes the address of who or what should handle the work and instructions on what to perform.

The request receiver does some work on your behalf and then returns some data or a confirmation message that the work has been done. This return process and value is the response part of the equation.

Figure 2. Request-Response lifecylce between two parties.

Request response lifecycles with a few more parts

We understand requests and responses on a basic level. Let’s get a little more complex. When we talk about the request-response lifecycle there are two parties usually involved: the client and the server.

The client could be anything. It could be your mobile phone, a laptop or tablet, or even a server. It’s simply the machine making a request for some action to take place. The server is less flexible as it is almost always a computer that can receive the request and will perform some action.

Figure 3. Request-Response lifecycle between a client and server.

Earlier, I mentioned that a request has an address and a set of instructions. The server can be seen as a toolbox with different tools in each compartment. Part of our request is telling the server which compartment to look at and which tool to use for a job. A hammer and a saw perform different actions.

Figure 4. Request-Response lifecycle with API receiving tool specific routes.

By telling the server which compartment to open, we also need to tell it what action to perform. Whether we want to get, create, update, or delete data or resources, we must pass this to the server as part of the request.

What you need to consider when working with requests and responses

Our request consists of a tool to use and an action to perform. What does an actual API request look like? Depending on the API type we are using it could look very different. Some of the popular API types include REST, SOAP, and Graph. We’ll focus on REST APIs.

REST APIs use CRUD actions (Create, Read, Update, and Delete). These are the core actions the API uses to allow users to retrieve, create, update, and destroy data records.

The actions passed in the request include: GET, PUT, PATCH, POST, and DELETE. These are paired with a URL (uniform resource locator) or URI (uniform resource identifier). Both URLs and URIs are used to specify where the API request action should be routed.

Figure 5. Request-Response lifecycle between client and server with CRUD operation and JSON response object.

Along with the REST method and the URL, we can include data such as headers and request bodies. The headers may help with authorization and adding extra context to the request. The optional body includes data for actions that create or update records. Here is what a request may look like:

Figure 6. Actual Request-Response lifecycle example (credit: https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/Messages)

Next steps with APIs

This wasn’t an exhaustive dive into APIs and how to use them. Over a half decade into Full Stack engineering I am still running into big and small topics that stretch my understanding of APIs. I hope this short article helps you better understand and articulate APIs and the request-response lifecycle to tech-literate and non-tech-literate people.

Key Takeaways

• The request-response lifecycle involves a client sending a request with an action (e.g., GET, POST) and a server responding with data or confirmation.
• REST APIs use CRUD actions (Create, Read, Update, Delete) paired with URLs to specify resources and operations.
• Requests include headers for context and optional bodies for creating/updating data, enhancing API functionality.
• APIs are like addresses: they route client requests to the right server “tool” for specific tasks.