HTTP Request vs Response: How Web Communication Works
A request is sent by the client to ask for a resource, and a response is returned by the server with data or a status code.
HTTP Request and Response
Every time you browse the web, your device sends an HTTP request and receives an HTTP response. Understanding this exchange is the key to understanding how websites, APIs, and web applications work.
What Is an HTTP Request
An HTTP request is a message sent by the client to a server, asking for a resource or instructing the server to perform an action. The client is usually a browser, a mobile app, or another server making an API call. Every request specifies what it wants, how it wants it, and sometimes includes data to be processed.
HTTP stands for HyperText Transfer Protocol. It is the foundation of data communication on the web and defines the rules for how messages are formatted and transmitted between clients and servers. Every time you click a link, submit a form, or an app fetches data in the background, an HTTP request is being made.
An HTTP request is made up of four main parts:
- Method: Defines what action to perform. Common methods include GET to retrieve data, POST to submit data, PUT to update a resource, PATCH to partially update a resource, and DELETE to remove one.
- URL: The address of the resource the client wants to interact with, such as
/tutorial/httpor/api/users/42. - Headers: Key-value pairs that carry metadata about the request, such as the content type being sent, the accepted response format, authentication tokens, and caching preferences.
- Body: Optional data included with the request. The body is used when the client needs to send data to the server, which is common with POST and PUT requests. GET requests typically do not include a body.
GET /tutorial/what-is-internet HTTP/1.1
Host: techyall.com
Accept: text/html
This example shows a GET request asking the server at techyall.com to return the page at /tutorial/what-is-internet. The Accept header tells the server the client would like to receive an HTML response. The server will use this information to decide what format to send back.
What Is an HTTP Response
After receiving and processing a request, the server sends back an HTTP response. The response contains the result of the request, whether that is the content that was asked for, a confirmation that an action was completed, or an error message explaining what went wrong.
An HTTP response contains three main parts:
- Status Code: A three-digit number that tells the client the outcome of the request. A 200 means success. A 404 means the resource was not found. A 500 means something went wrong on the server side.
- Headers: Metadata about the response, such as the content type of the body, caching instructions, cookies to set, and security-related directives.
- Body: The actual content being returned. This could be an HTML page, a JSON object from an API, an image, a file download, or anything else the client requested.
HTTP/1.1 200 OK
Content-Type: text/html; charset=UTF-8
<html>...</html>
In this example, the server responded with a 200 status code indicating the request was successful. The Content-Type header tells the browser that the body contains HTML content encoded in UTF-8, so the browser knows to render it as a web page rather than treat it as plain text or some other format.
Request and Response Flow
Every interaction on the web follows the same basic pattern. The client initiates by sending a request. The server receives it, processes it, and sends a response back. This cycle repeats for every resource the client needs, including the HTML page itself, the CSS stylesheets, JavaScript files, images, and any API calls made after the page loads.
A single page load can involve dozens of individual request and response cycles happening in sequence or in parallel. Modern browsers open multiple connections to the same server to fetch resources concurrently, which is why pages with many assets can still load quickly despite each asset requiring its own exchange.
HTTP Headers
Headers carry important information that helps the client and server communicate beyond just the resource being requested. Request headers tell the server about the client's preferences and capabilities. Response headers tell the client how to handle what is being returned.
Some commonly used request headers include Authorization for sending authentication credentials, Content-Type for declaring the format of the request body, Accept for telling the server what formats the client can handle, and Cookie for sending session data back to the server. On the response side, Cache-Control tells the client how long it can store the response before checking again, Set-Cookie instructs the browser to store a cookie, and Location is used with redirect status codes to tell the client where to go next.
Common HTTP Status Codes
Status codes are grouped by their first digit. Codes in the 200 range indicate success. Codes in the 300 range indicate redirects. Codes in the 400 range indicate client errors, meaning the problem is with the request itself. Codes in the 500 range indicate server errors, meaning something went wrong while the server was trying to handle the request.
| Code | Meaning | When It Occurs |
|---|---|---|
| 200 | OK | Request succeeded and content was returned |
| 201 | Created | A new resource was successfully created |
| 204 | No Content | Request succeeded but there is no body to return |
| 301 | Moved Permanently | The URL has permanently changed to a new address |
| 302 | Found (Redirect) | Temporary redirect to another URL |
| 400 | Bad Request | The request was malformed or contained invalid data |
| 401 | Unauthorized | Authentication is required but was not provided |
| 403 | Forbidden | Authenticated but not permitted to access the resource |
| 404 | Not Found | The server could not find the requested resource |
| 500 | Internal Server Error | An unexpected error occurred on the server |
HTTP Methods in Requests
The HTTP method in a request tells the server what kind of action the client wants to perform. Using the correct method matters both for correctness and for predictability. APIs and browsers rely on method semantics to make decisions about caching, safety, and idempotency.
| Method | Action | Common Use |
|---|---|---|
| GET | Retrieve data | Loading a web page, fetching API data |
| POST | Submit data | Submitting a form, creating a new record |
| PUT | Replace a resource | Replacing an existing resource entirely |
| PATCH | Partial update | Updating specific fields of a resource |
| DELETE | Remove data | Deleting a record through an API |
| HEAD | Retrieve headers only | Checking if a resource exists without downloading its body |
| OPTIONS | Describe allowed methods | Preflight checks in CORS requests |
GET requests are considered safe because they should not change any data on the server. They are also idempotent, meaning making the same GET request ten times should produce the same result as making it once. POST requests are neither safe nor idempotent, because each POST may create a new resource. DELETE is idempotent because deleting the same resource twice has the same end result as deleting it once, even if the second attempt returns a 404.
The Request Body
When a client needs to send data to the server, it includes that data in the request body. This is most common with POST and PUT requests. A login form, for example, sends the username and password as the request body. An API creating a new user sends the user's details in the body.
The format of the request body is declared using the Content-Type header. For JSON data sent to an API, the header is Content-Type: application/json. For a traditional HTML form submission, it is Content-Type: application/x-www-form-urlencoded. For file uploads, it is Content-Type: multipart/form-data. The server uses this header to parse the body correctly.
Frequently Asked Questions
- What is the difference between a request and a response?
A request is the message the client sends to the server to ask for a resource or trigger an action. A response is the server's reply, which includes a status code indicating the outcome and usually a body containing the requested data or a description of what happened. - Can a server send data without a request?
Not with standard HTTP. HTTP is a request-response protocol, meaning communication is always initiated by the client. WebSockets and Server-Sent Events are separate technologies that allow servers to push data to clients without waiting for a request, which makes them suitable for real-time features like live notifications or chat. - What does a 404 error mean?
A 404 means the server received the request successfully and understood it, but could not find any resource at the URL that was requested. It is a client-side error in the sense that the URL is wrong or the resource has been removed, not that the server itself has a problem. - What is the difference between 401 and 403?
A 401 Unauthorized response means the client has not provided authentication credentials, or the credentials provided were invalid. It is an invitation to authenticate and try again. A 403 Forbidden response means the server recognised the client's identity but the client does not have permission to access that resource. Logging in again will not help with a 403. - Why do some requests have a body and others do not?
GET and HEAD requests are designed to retrieve information and do not carry a body because there is no data to send. POST, PUT, and PATCH requests are designed to send data to the server, so they include a body containing that data. DELETE requests typically do not include a body, though the HTTP specification technically allows it.
Conclusion
HTTP requests and responses are the foundation of how the web works. Every page load, form submission, and API call follows this same exchange between client and server. Understanding the structure of a request, what each status code means, and how headers control behaviour on both sides gives you the knowledge to debug web issues confidently, design cleaner APIs, and build more reliable web applications. To go deeper, explore HTTP methods and HTTP headers.