Backend Basics #1

2026-03-26·15 min Read

Let us start backend from the very basics, HTTP Requests

HTTP stands for HyperText Transfer Protocol. It is the foundation of data communication on the World Wide Web. HTTP defines how messages are formatted and transmitted, and how web servers and browsers should respond to various commands.

When you enter a URL in your web browser, it sends an HTTP request to the server hosting the website. The server then processes the request and sends back an HTTP response, which contains the requested resource (like a webpage, image, or data) or an error message if something went wrong.

HTTP PROTOCOL

It follows two core principles:

Statelessnes - NO memory of past interactions, The request carries all the necessary information for the server to process.
Client Server Model - Client sends all the information to the server, the server waits for requests from the client. Request are usually given by the client, HTTP uses TCP protocol which is more reliable.

What we use now is HTTP / 3 which uses QUIC and is built on UDP

Request message is sent by the client, Response message is recieved by the client

Types of headers

Request Headers- User agent, authorizzation, cookie, accept
General headers - data. cache-control, connection
Representation Headers - Content-type (json or html), content-length, context-encoding, Etag (unique identifier used for caching)
Security Headers - Strict Transport Security HSTS (ensures communication over HTTPS), Content Security Policy CSP (prevents javascript stuff), X frame options, X content type options, (Browser does not try to guess type of content) set Cookie (secures cookies by making them innaccessible to javascript)

HTTP is highly extensible since headers can be easily added and customized without changing the protocol, thus we can also create custom headers and all

HTTP headers act as remote control for the server side headers like cache control etc.

The client can authenticate using the Authorization header.

HTTP METHODS

Kinds of actions the client can reference on the server Methods provide the intent of client on the server

GET to fetch data, cannot modify
POST can send data to server
PATCH can be used to update the data and appends to the previous header
PUT is used to update but data replaces the previous header
DELETE is used to delete a data

PATCH partially updates a resource, while PUT replaces it entirely.

Idempotent and Non Idempotent

Idempotent means repeating the request gives the same result.

GET, PUT, DELETE are idempotent since the result is always the same and data isn't changed

POST is non idempotent because there are two different results for the same kind of request

OPTIONS method

Used to fetch capabilities of the server for the CORS request

CORS Requests

1. Simple Request -

Frontend at example.com and we make a GET request

GET /api/products/123 HTTP/1.1
Host: api.example.com
Origin: http://example.com
Accept: application/json

The request reaches the api.example.com

HTTP/1.1 200 OK
Content-Type: application/json
Access-Control-Allow-Origin: http://example.com

{
    "product": {
        "id": 123,
        "name": "Product Name",
        "price": 19.99
    }
}

When the browser doesnt see the Access-Control-Allow-Origin header, it blocks the CORS flow

2. Preflighted Request

The method is not GET POST or HEAD ( eg. PUT DELETE) The request includes non simple headers (like authorization, x-custom-header) The request the content type other than application/x-www-form-urlencoded, multipart/form-data or text/plain

This is when we see the use of options method

it has OPTIONS method EXAMPLE

OPTIONS /api/products/123 HTTP/1.1
Host: api.example.com
Origin: http://example.com
Access-Control-Request-Method: PUT
Access-Control-Request-Headers: Authorization

If the server supports CORS, it responds with 204 (No Content)

HTTP/1.1 204 No Content
Access-Control-Allow-Origin: http://example.com
Access-Control-Allow-Methods: PUT, DELETE
Access-Control-Allow-Headers: Authorization
Access-Control-Max-Age: 86400

Response Status Codes

Information 1XX -

Recieved the headers, used in large uploads Switching protocols

Success 2XX -

200 - Successful request
201 - Successful request, new resource created
204 - Preflight request with no Content, Succcesful request

Redirection 3XX -

301 - Route moved permenatly
302 - Temporarily relocated to another url
304 - Not been modified since the last time it was accessed

Client Error 4XX -

400 - Bad Request, when invalid data is shared
401 - Unauthorized, When client isn't authenticated / unauthorized
403 - Resource access Forbidden
404 - Not Found, Resource unavailable / delete
405 - Method not allowed, trying to PUT to a GET endpoint
409 - Conflict, same name exists
429 - Too many requests

Server Error 5XX -

500 - Internal server error, something unexpected occured in the server
501 - Not supported, might be in future
502 - Bad Gateway, server acts as proxy and upstream server returns invalid response (nginx)
503 - Service is temporary unavailable
504 - Upstream server failed to respond within time out period (along with proxy server)

HTTP Caching

Reusing old data if data isn't changed

HTTP/1.1 200 OK
X-Powered-By: Express
Access-Control-Allow-Origin: *
Cache-Control: max-age=10, public
ETag: 3141
Last-Modified: Thu, 26 Mar 2026 16:59:03 GMT
Content-Type: application/json; charset=utf-8
Content-Length: 123
Date: Thu, 26 Mar 2026 17:00:00 GMT
Connection: keep-alive
Keep-Alive: timeout=5

{
    "content": "This is updated content",
    "lastModified": "Fri, 27 Mar 2026 12:00:00 GMT",
    "etag": "3141"
}

Cache-Control ETag Last-Modified are used for caching, ETag then hashes the request and is returned.

After reload,

Request:

GET /api/data HTTP/1.1
Host: api.example.com
If-None-Match: 3141

It checks the If-None-Match: 3141 header which contains the value returned by ETag. The server responds with 304 not modified

GENUINELY 🤯🤯🤯🤯🤯

HTTP caching works at the protocol level (browser/CDN), while React Query handles client-side state caching. They solve different problems and are often used together.

Content Negotiation

This is where the client and the sevrer agree for a way to send and recieve data. There are 3 things

Content
Format
Encoding

These use the Accept header to send said requests

Accept -> Tells the server which content types the client can process (eg. application/json, text/html)
Accept-Language -> Preffered languages for the response (eg. en-US, fr-FR)
Accept-Encoding -> Preffered encoding methods for the response (eg. gzip, deflate)

HTTP supports response compression based on what was sent in the Accept-Encoding header. If the client indicates that it can handle gzip encoding, we use gzip encoding to encode files if the response files are very large

Persistent Connections and Keep-Alive

Persistent connections allow multiple HTTP requests and reponses to be sent over a single TCP connection, instead of opening a new connection for each request.

In HTTP/1.1, The connections are persistent by default, which reduces latency and improves performance by avoiding the overhead of establishing new connections for each request. The Connection: keep-alive header is used to indicate that the connection should be kept alive for multiple requests and responses.

Modern protocols like HTTP/2 and HTTP/3 have built-in support for multiplexing multiple requests and responses over a single connection, further improving performance and reducing latency.

Handling large requests and responses

Multipart Requests

Multipart requests allow a client to send large or complex data (such as file uploads) in multiple parts within a single HTTP request.

Each part is separated using a boundary string, defined in the Content-Type header:
```
Content-Type: multipart/form-data; boundary=----XYZ
```
This enables sending different types of data (e.g., text + files) together efficiently.
Streaming Responses

Streaming responses allow the server to send data to the client incrementally, rather than waiting for the entire response to be ready.

This is useful for real-time updates such as notifications, logs, or live feeds.

A common example is Server-Sent Events (SSE), which uses:
```
Content-Type: text/event-stream
```
The connection remains open, and the server continuously pushes new data as it becomes available.
SSL, TLS, and HTTPS

SSL (Secure Sockets Layer): The original encryption protocol (now deprecated)

TLS (Transport Layer Security): The modern, secure successor to SSL

HTTPS: HTTP running over TLS (encrypted HTTP communication)

TLS ensures:

Encryption (data cannot be read in transit) Integrity (data is not modified) Authentication (server identity is verified)