Request Response | Software.Land

Request Response

Overview

Request / Response is one of the most basic and fundamental forms of communication between two nodes in a system. As the name implies, it involves a request by the client (or caller), followed by a response by the server (or callee) after receipt of the request. This communication paradigm, while not exclusive to network communication, is predominantly associated to this context, particularly at Layer 7 of the OSI Model. TCP is typically used as the transport layer (Layer 4) for its built-in optimization with ACKs for accurate delivery (rather than timely delivery), given that the response by the server depends on the request by the client.

If you look closely, you’ll see the paradigm can be observed everywhere in all aspects of computers. Some examples include:

  • Function in an application calling another with arguments and receiving a response.
  • Database queries where the result is the response. Note that this exact example assumes logging in directly into the DB engine. It’s not to be confused with the Request/Response paradigm that is typically used to communicate with a DB engine via its client through a network.
  • Inter-Process Communication (IPC) where one process requests information from another.

The rest of this blog post focuses on the topic of Request Response from the perspective of network requests.

The Request

If the underlying protocol of the network request is HTTP (as is commonly the case), the request has the following structure:

  1. Method/Verb: The most common methods defined in the original HTTP protocol are:
    • GET (no payload should be included): Fetches a resource (such as a webpage).
    • POST (should typically include a payload): Submits data or creates a resource (such as a new user).
    • PUT (should typically include a payload): Creates or updates a resource.
    • DELETE (should typically not include a payload): Deletes a resource.
  2. Endpoint: The target destination of the request.
  3. Headers: Metadata of the request. May include:
    • Authentication token.
    • Cookie (metadata about the user’s session for a website).
    • Information about the user making the request.
  4. Body (payload): Data being sent.
  5. Parameters: Additional data that is appended to the endpoint. Often used with GET method to specify query filters.

There do exist protocols that are built on top of HTTP that do not use all the features mentioned above (but do use other HTTP features). One such example is gRPC.

The fields above are typically accessible by a developer via a library API that provides network request capabilities.

The Response

  1. Status: In HTTP1 (a text-based protocol), this field is returned as the first line of the response, and it looks like: HTTP/1.1 200 OK. In HTTP/2 (a binary-based protocol), to enhance efficiency, the status is strictly 3 digits and does not include a phrase such as OK.
  2. Headers: Similar to requests, response headers provide metadata about the response.
  3. Body: Data being returned.

Having mentioned HTTP1 and HTTP/2, it’s worth noting that HTTP3 is the most recent version as of 2023. Improvements center around reliability and performance.

Conclusion

The Request / Response model stands as a cornerstone in the architecture of computing, underpinning numerous fundamental processes, such as web browsing and inter-service communication in distributed systems.

To learn about some nuances between Request / Response and Event Driven Systems, head on over to the blog post: Event Driven Architecture.

To learn about some nuances between Request / Response and Asynchronous vs Synchronous, head on over to the blog post: Asynchronous vs Synchronous.

To be updated in the new year with diagrams and an exploration into use cases.

Author

Sam Malayek

Sam Malayek works in Vancouver, using this space to fill in a few gaps. Opinions are his own.