Understanding HTTP: Basic Concepts, Request Methods, and Status Codes

HTTP is one of the most fundamental and critical communication protocols in the world of the Internet. It defines how browsers and servers exchange data and is the core rule for all network behaviors, including webpage loading, image display, video playback, and API communication. Without HTTP, there would be no internet experience as we know it today: from opening a webpage, checking the weather, scrolling through social media, to online shopping and mobile payments, all content is reliably and efficiently transmitted globally via HTTP.

It acts as the “universal language” and “transport system” of the Internet, allowing countless different devices, systems, and services to work together and connect seamlessly, forming a vast and interconnected ecosystem. The evolution of HTTP (from 1.0 to 3.0) has continuously driven improvements in network speed, security, and stability, becoming an indispensable infrastructure for the modern digital world.

Basic Concepts

What is HTTP

HTTP (HyperText Transfer Protocol) is an application layer protocol used for transmitting hypermedia documents (such as HTML). It is the foundation of data communication on the World Wide Web.

Core Features:

  • • Simple: HTTP messages are easy to read and understand
  • • Extensible: Functionality can be easily extended through headers
  • • Stateless: Each request is independent
  • • Based on TCP/IP: Operates on top of a reliable transport layer

Historical Development:

1991: HTTP/0.9 was born, supporting only the GET method
1996: HTTP/1.0 was released, adding headers and status codes
1997: HTTP/1.1 was released, supporting persistent connections
2015: HTTP/2 was released, introducing binary framing
2022: HTTP/3 was standardized, based on the QUIC protocol

How HTTP Works

HTTP follows the classic client-server model:

Client (Browser)                     Server
    |                                   |
    |------ HTTP Request ----------------->|
    |                                   | Process Request
    |                                   | Find Resource
    |<----- HTTP Response -------------------|
    |                                   |
Display Content                              

Complete Communication Process:

  1. 1. The client initiates a DNS query to obtain the server’s IP
  2. 2. Establish a TCP connection (three-way handshake)
  3. 3. The client sends an HTTP request
  4. 4. The server processes the request and returns an HTTP response
  5. 5. The client receives the response and renders the content
  6. 6. Close the TCP connection (four-way handshake) or keep the connection alive (Keep-Alive)

HTTP Message Structure

HTTP Request Structure:

GET /index.html HTTP/1.1              ← Request Line
Host: www.example.com                 ← Header Section
User-Agent: Mozilla/5.0
Accept: text/html
Connection: keep-alive
                                      ← Empty Line (Separator)
Request Body (optional)                          ← Body Section

HTTP Response Structure:

HTTP/1.1 200 OK                       ← Status Line
Content-Type: text/html               ← Header Section
Content-Length: 1234
Date: Mon, 20 Nov 2024 12:00:00 GMT
                                      ← Empty Line (Separator)
<html>                                ← Body Section
  <body>Hello World</body>
</html>

Characteristics of HTTP

1. Statelessness

HTTP itself does not retain previous request and response information. Each request is independent.

Advantages:

  • • The server does not need to maintain state information
  • • Reduces server load
  • • Easy to scale

Disadvantages:

  • • Requires additional mechanisms (Cookies, Sessions) to maintain state
  • • Each request must transmit complete information

2. Persistent Connections (HTTP/1.1+)

Persistent connections (also known as Keep-Alive) were introduced in HTTP/1.1.

Traditional Method (HTTP/1.0):
Request 1 → Response 1 → Close Connection
Request 2 → Response 2 → Close Connection
(Each request establishes a new connection)

Persistent Connection (HTTP/1.1):
Request 1 → Response 1
Request 2 → Response 2
Request 3 → Response 3
(One connection can send multiple requests)

3. Pipelining

HTTP/1.1 supports pipelining, allowing multiple requests to be sent simultaneously on the same connection without waiting for responses.

Client: Request 1 → Request 2 → Request 3
Server:      ← Response 1 ← Response 2 ← Response 3
(Responses returned in order)

4. Extensibility

HTTP functionality can be easily extended through custom headers.

X-Custom-Header: custom-value
X-Request-ID: 12345
X-API-Version: v2

HTTP Request Methods

Common Methods Explained

GET

Used to retrieve resources, the most commonly used method.

GET /api/users/123 HTTP/1.1
Host: example.com

Characteristics:

  • • Parameters in the URL (query string)
  • • Can be cached
  • • Can be bookmarked
  • • Length is limited (browser and server limitations)
  • • Idempotent operation (multiple requests yield the same result)

POST

Submits data to the server, commonly used to create resources.

POST /api/users HTTP/1.1
Host: example.com
Content-Type: application/json

{
  "name": "John",
  "email": "[email protected]"
}

Characteristics:

  • • Parameters in the request body
  • • Not cacheable
  • • Cannot be bookmarked
  • • Length is theoretically unlimited
  • • Non-idempotent operation (multiple requests may yield different results)

PUT

Updates a resource by replacing it entirely.

PUT /api/users/123 HTTP/1.1
Host: example.com
Content-Type: application/json

{
  "name": "John Updated",
  "email": "[email protected]",
  "age": 30
}

Characteristics:

  • • Idempotent operation
  • • Typically used for complete resource updates
  • • Can create if the resource does not exist

PATCH

Partially updates a resource.

PATCH /api/users/123 HTTP/1.1
Host: example.com
Content-Type: application/json

{
  "email": "[email protected]"
}

Characteristics:

  • • Only updates specified fields
  • • Saves bandwidth
  • • Non-idempotent operation

DELETE

Deletes a resource.

DELETE /api/users/123 HTTP/1.1
Host: example.com

Characteristics:

  • • Idempotent operation
  • • Deletes the specified resource

HEAD

Similar to GET, but only returns headers, not the body.

HEAD /api/users/123 HTTP/1.1
Host: example.com

Uses:

  • • Check if a resource exists
  • • Get metadata about the resource (size, modification time)
  • • Check link validity

OPTIONS

Queries the methods supported by the server.

OPTIONS /api/users HTTP/1.1
Host: example.com

Response:

HTTP/1.1 200 OK
Allow: GET, POST, PUT, DELETE, OPTIONS
Access-Control-Allow-Methods: GET, POST, PUT, DELETE

Uses:

  • • CORS preflight requests
  • • Query server capabilities

CONNECT

Establishes a tunnel connection, used for HTTPS proxies.

CONNECT www.example.com:443 HTTP/1.1
Host: www.example.com

TRACE

Echoes the request received by the server, used for diagnostics.

TRACE /api/test HTTP/1.1
Host: example.com

Note: Due to security issues, TRACE is often disabled.

Comparison of Methods

Method Idempotent Safe Cacheable Request Body Response Body Main Use
GET Yes Yes Yes No Yes Retrieve Resource
POST No No Yes Yes Yes Create Resource
PUT Yes No No Yes Yes Complete Update
PATCH No No No Yes Yes Partial Update
DELETE Yes No No Yes Yes Delete Resource
HEAD Yes Yes Yes No No Get Metadata
OPTIONS Yes Yes No No Yes Query Capabilities

Idempotency: Executing multiple times produces the same resultSafety: Does not modify resource state

RESTful API Design

REST (Representational State Transfer) is an architectural style for building network services that utilizes the HTTP protocol as the underlying communication mechanism and defines specific design principles and constraints based on it. RESTful APIs use HTTP methods to perform operations, but it is not merely a reference to the naming of HTTP methods; it standardizes the structure and behavior of APIs by adhering to some basic design principles (such as resource representation, statelessness, and uniform interface).

Using HTTP methods to design RESTful APIs:

Resource: Users (users)

GET    /users          # Retrieve user list
GET    /users/123      # Retrieve specific user
POST   /users          # Create new user
PUT    /users/123      # Complete update user
PATCH  /users/123      # Partial update user
DELETE /users/123      # Delete user

Resource: User Orders (users/123/orders)

GET    /users/123/orders       # Retrieve user order list
GET    /users/123/orders/456   # Retrieve specific order
POST   /users/123/orders       # Create order for user
DELETE /users/123/orders/456   # Delete specific order

HTTP Status Codes

Status Code Classification

Status codes consist of three digits, with the first digit defining the category of the response:

1xx: Informational Status Codes
2xx: Success Status Codes
3xx: Redirection Status Codes
4xx: Client Error Status Codes
5xx: Server Error Status Codes

Common Status Codes Explained

1xx Informational Status Codes

100 Continue

The client should continue its request
Typically used when the client sends Expect: 100-continue

101 Switching Protocols

The server is switching protocols
Commonly seen in WebSocket upgrades

Example:

HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade

2xx Success Status Codes

200 OK

Request succeeded
The most common status code

201 Created

Resource has been created
Commonly used after a successful POST request

Example:

HTTP/1.1 201 Created
Location: /api/users/124
Content-Type: application/json

{
  "id": 124,
  "name": "John"
}

204 No Content

Request succeeded, but no content returned
Commonly used for DELETE requests

206 Partial Content

Partial content
Used for resuming downloads

Example:

HTTP/1.1 206 Partial Content
Content-Range: bytes 0-1023/5000
Content-Length: 1024

3xx Redirection Status Codes

301 Moved Permanently

Permanently redirected
Search engines will update their index

Example:

HTTP/1.1 301 Moved Permanently
Location: https://www.example.com/new-page

302 Found

Temporarily redirected
Search engines will not update their index

304 Not Modified

Resource not modified
Can use cached version

Example:

Request:
GET /image.jpg HTTP/1.1
If-Modified-Since: Mon, 01 Jan 2024 00:00:00 GMT

Response:
HTTP/1.1 304 Not Modified

307 Temporary Redirect

Temporary redirect
Keeps the request method unchanged

308 Permanent Redirect

Permanently redirected
Keeps the request method unchanged

4xx Client Error Status Codes

400 Bad Request

Request syntax error
The server cannot understand the request

401 Unauthorized

Unauthorized
Authentication required

Example:

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer realm="example"

403 Forbidden

Access forbidden
The server refuses the request

404 Not Found

Resource not found
The most common error status code

405 Method Not Allowed

Method not allowed
For example, using POST on a read-only resource

Example:

HTTP/1.1 405 Method Not Allowed
Allow: GET, HEAD

408 Request Timeout

Request timeout
The server timed out waiting for the request

409 Conflict

Request conflict
For example, version conflict

410 Gone

Resource has been permanently deleted
More specific than 404

413 Payload Too Large

Request body too large
Exceeds server limits

414 URI Too Long

URI too long
Usually occurs when the GET request URL is too long

415 Unsupported Media Type

Unsupported media type
For example, sending XML but the server only accepts JSON

429 Too Many Requests

Too many requests
Triggers rate limiting

Example:

HTTP/1.1 429 Too Many Requests
Retry-After: 3600
X-RateLimit-Limit: 1000
X-RateLimit-Remaining: 0

5xx Server Error Status Codes

500 Internal Server Error

Internal server error
General error response

501 Not Implemented

Function not implemented
The server does not support the request method

502 Bad Gateway

Gateway error
The proxy server received an invalid response from the upstream server

503 Service Unavailable

Service unavailable
The server is temporarily unable to handle the request

Example:

HTTP/1.1 503 Service Unavailable
Retry-After: 120

504 Gateway Timeout

Gateway timeout
The proxy server timed out waiting for a response from the upstream server

Best Practices for Status Codes

Selecting Appropriate Status Codes:

// Successfully created resource
return res.status(201).json({ id: newUser.id });

// Successfully deleted, no content returned
return res.status(204).send();

// Resource not found
return res.status(404).json({ error: "User not found" });

// Validation failed
return res.status(400).json({ error: "Invalid email format" });

// Unauthorized
return res.status(401).json({ error: "Authentication required" });

// Insufficient permissions
return res.status(403).json({ error: "Insufficient permissions" });

// Server error
return res.status(500).json({ error: "Internal server error" });

To be continued, stay tuned~

Understanding HTTP: Basic Concepts, Request Methods, and Status Codes

Leave a Comment