Understanding HTTP Methods and Status Codes

HTTP: The Language of the Web

HTTP (HyperText Transfer Protocol) is the foundation of data communication on the web. Every time a browser loads a page, a mobile app fetches data, or two services communicate, they use HTTP.

As a backend developer, you will spend a significant amount of time working with HTTP. Understanding it deeply means you can:

• Design clean, predictable APIs
• Diagnose bugs by reading request and response details
• Write middleware that handles authentication, logging, and error handling
• Make informed decisions about caching and performance

The Full HTTP Request Structure

An HTTP request consists of four parts:

1. Request Line

POST /api/users HTTP/1.1

This tells the server: "I want to POST data to /api/users using HTTP version 1.1."

2. Headers

Host: api.example.com
Content-Type: application/json
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9

Headers carry metadata about the request. Common headers include:

• Content-Type: The format of the request body (e.g., application/json)
• Authorization: The authentication token
• Accept: The format the client expects in the response

3. Blank Line

A blank line separates the headers from the body.

4. Request Body (optional)

{
  "name": "Ngozi Eze",
  "email": "ngozi@example.com",
  "password": "securepassword123"
}

GET and DELETE requests typically have no body. POST and PUT requests carry data in the body.

HTTP Methods in Depth

GET

• Purpose: Retrieve data without modifying anything
• Body: None
• Safe: Yes (no side effects)
• Idempotent: Yes (calling it multiple times returns the same result)

GET /api/products?category=electronics&limit=10

POST

• Purpose: Create a new resource
• Body: Required (the new resource's data)
• Safe: No
• Idempotent: No (calling it twice creates two resources)

PUT

• Purpose: Replace an entire resource
• Body: Required (the complete updated resource)
• Idempotent: Yes (replacing with the same data gives the same result)

PATCH

• Purpose: Partially update a resource
• Body: Required (only the fields to update)

PATCH /api/users/123
{ "email": "new-email@example.com" }

DELETE

• Purpose: Remove a resource
• Body: Usually none
• Idempotent: Yes (deleting something already deleted is still "deleted")

HTTP Status Codes in Depth

Status codes are organised into five classes:

1xx: Informational

Rarely seen in everyday API work. Signals that the request was received and processing is continuing.

2xx: Success

3xx: Redirection

4xx: Client Errors

5xx: Server Errors

Designing Good API Responses

A well-designed API response tells the client exactly what happened. Here is a pattern many teams use:

Success Response:

{
  "success": true,
  "data": {
    "id": 123,
    "name": "Ngozi Eze"
  }
}

Error Response:

{
  "success": false,
  "error": {
    "code": "VALIDATION_ERROR",
    "message": "Email address is invalid"
  }
}

Consistent response shapes make it much easier for frontend developers to consume your API.

Headers You Will Use Regularly

Content-Type: Tells the receiver what format the body is in.

Content-Type: application/json

Authorization: Carries the authentication token.

Authorization: Bearer <your-token-here>

CORS Headers: Control which domains can access your API.

Access-Control-Allow-Origin: https://yourapp.com

Understanding headers is essential because many common backend bugs -- like authentication failures or CORS errors -- are caused by missing or incorrect headers.