Request & Response Communication Design Pattern

What actually is a request and response - the most popular communication design pattern we see almost everywhere?

Intro

This elegant, classic pattern is something we hear a lot in our work as developers. But what are they really? What is their relationship? Can we see it somewhere else then HTTP? You will learn about this and more in this short article.

Definitions

Lets start from defining what exactly are the request and response, two heroes playing main part in this communication pattern play we are talking about.

Request - is a call made by a client (initiator) to a server (receiver), aiming to invoke an action, retrieve data, or submit data for processing. It includes all the necessary information the server needs to fulfil the request.

Its structure usually includes:

1. Intent (action) - specifies the purpose of the request. If we want to retrieve, or delete some information etc.

Example: Http request methods: GET, POST, PUT, DELETE, PATCH, and less known HEAD, OPTION, TRACE, CONNECT

1. Target or Resource identifier - points to specific resource or service the request is directed at.

Example: In Http its an URL, but in other protocols it may be something different.

1. Metadata - additional information that describes or modifies the request. This includes directives on how the request should be handled, authentication information, or context about the initiator.

2. Payload - data sent for processing or necessary for completing the request. The structure of this data can vary widely across different protocols and systems. It very often is optional.

3. Separator(s) - in contexts where a request can carry multiple pieces of information or complex data structures, separators are used to delineate these sections clearly.

Response - is a reply generated by the server (receiver) after parsing and processing the request. It serves to provide an outcome of the requested action, data retrieval, or its submission.

Its structure usually includes:

1. Outcome (status) - communicates the result of processing the request, which can indicate success, failure, or the need for further action.

2. Metadata - supplementary information about the response itself, which can include details about the server or receiver, instructions for the initiator, or context about the processing of the request.

3. Payload - the actual content or data being returned in response to the request. This can be the requested data, a confirmation of a successful operation, or details about an error or failure.

4. Separators (when applicable) - Especially relevant in complex responses containing multiple parts or structured data, separators ensure clear demarcation between different sections of the response content.

Both client and server need to understand the structure of both response and request, to parse and process it correctly.

Communication Pattern

Now that we know what request, response are and that they are part of some kind of communication design pattern, we should explain what communication design pattern is and how response request communication works.

The communication design pattern is basically a description of how receiver and initiator sides should be talking with each other.

Request Response Model:

1. Everything starts from the client, sending the request to the server. This is a place where request is defined.

2. Server receives the request and parses it. At this point in time server parses received request and tries to understand where important information in the stream of send data starts and ends, then breaking it into parts and grasping what is being asked from it.

3. After parsing the request server knows what it should do, so it processes/executes the request.

4. After execution of the request, server sends the response back to the client, usually with the information that was requested, status code, maybe error etc.

5. Client parses the response and consumes it.

That's pretty much it. An overview of the flow that happens during request response communication.

Real Life Examples

1. Web - browsers send requests for web pages, and servers respond with the HTML content and resources needed to render those pages.

2. HTTP - like mentioned a bit before, its one of the foundational protocols for the web, where clients issue requests for resources, and servers return responses containing the requested information.

3. DNS (Domain Name System) - Clients query DNS servers with a hostname, and the server responds with the corresponding IP address to facilitate network connections.

4. SSH (Secure Shell) - A client sends a connection request to a server, and upon successful authentication, the server responds to execute commands or transfer files securely.

5. SQL (Structured Query Language) - In databases, clients send SQL queries as requests to retrieve or manipulate data, and the database server processes these queries and returns results or confirmation.

6. APIs (Application Programming Interfaces) - Clients send requests to access services or data exposed by APIs, and the servers process these requests and return the desired information or outcomes.

Costs

Everything has a cost. Sometimes it's not very obvious. In this case the main cost we have to deal with is time. Writing request take time, sending it takes time, parsing and processing by the server takes time (and is usually the main focus of us developers when request response takes too much time).

Its important to understand that each our decision comes at a cost, just like in life - software is not different.

---

Hope you liked this short introduction to Request Response Design Pattern. If you found some mistakes, or maybe you feel something should be added to it, feel free to reach out to me. Cheers!