HTTP (HyperText Transfer Protocol)

Definition

HTTP (HyperText Transfer Protocol) is the foundation protocol of the World Wide Web and modern APIs. Every time you visit a website, stream a video, or use a mobile app, HTTP is working behind the scenes to transfer data between your device (the client) and remote servers.

HTTP is a request-response protocol. The client sends a request (like “give me the homepage”), and the server responds (with the HTML, images, data, etc.). HTTP is stateless - each request is independent, the server doesn’t remember previous requests. This simplicity makes HTTP incredibly scalable.

HTTP operates on top of TCP/IP, typically using port 80. The protocol defines methods (GET, POST, PUT, DELETE) for different types of requests, status codes (200 OK, 404 Not Found) to indicate results, and headers to pass metadata. While originally designed for transferring hypertext documents, HTTP has evolved into the universal protocol for APIs and web services.

Example

Web Browsing: When you type example.com into your browser, it sends GET / HTTP/1.1 to the server. The server responds with HTTP/1.1 200 OK plus the HTML content. Every image, CSS file, and script on that page triggers additional HTTP requests.

Mobile App API: A weather app sends GET /api/weather?city=NYC HTTP/1.1 to get current conditions. The server responds with HTTP/1.1 200 OK and JSON data containing temperature, humidity, and forecast.

File Upload: When you upload a profile picture, the app sends POST /api/users/123/avatar HTTP/1.1 with the image data in the request body. The server responds with HTTP/1.1 201 Created and the new image URL.

API Integration: Slack’s API uses HTTP for all interactions. Posting a message is POST /api/chat.postMessage with the message text. Getting channel history is GET /api/conversations.history?channel=C1234. All over HTTP.

Analogy

The Restaurant Order System: HTTP is like ordering at a restaurant:

• You (client) make a request: “I’d like the burger, medium rare”
• The kitchen (server) processes it and sends a response: Your burger arrives
• Each order is independent - the waiter doesn’t need to remember what you ordered last week
• The menu is like API documentation, showing available options (HTTP methods)
• The ticket number is like a request ID for tracking
• The food delivery is like the response body with your data

The Post Office: Sending letters via HTTP:

• You write a letter (request body) with an address (URL)
• You choose a service type (HTTP method): regular mail (GET), certified (POST), return receipt (PUT)
• The postal service delivers it to the destination (server)
• You get a response: delivery confirmation (200 OK) or “address not found” (404)
• Each letter is independent - no memory of previous mailings (stateless)

Code Example

// HTTP Request
GET /api/users/123 HTTP/1.1
Host: api.example.com
Accept: application/json
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...

// HTTP Response
HTTP/1.1 200 OK
Content-Type: application/json
Content-Length: 82
Cache-Control: max-age=300

{
  "id": 123,
  "name": "Alice",
  "email": "[email protected]",
  "created": "2025-01-01T00:00:00Z"
}

Diagram

sequenceDiagram
participant Client
participant Server
Client->>Server: HTTP Request
GET /api/resource
Server->>Server: Process request
Server->>Client: HTTP Response
200 OK + Data
Note over Client,Server: Stateless: each request is independent

Security Notes

Best Practices

1. Use HTTPS, not HTTP, for all production traffic
2. Choose appropriate HTTP methods (GET for read, POST for create, PUT/PATCH for update, DELETE for remove)
3. Return correct status codes (200 for success, 404 for not found, 500 for server error)
4. Include relevant headers (Content-Type, Cache-Control, Authorization)
5. Keep requests stateless - don’t rely on server-side sessions
6. Version your APIs in the URL or headers
7. Implement proper error handling with descriptive messages
8. Use compression (gzip, br) for large responses

Common Mistakes

Using HTTP instead of HTTPS for sensitive data, returning 200 for all responses (even errors), putting credentials in URL parameters, not setting Content-Type headers, ignoring caching headers, not implementing timeouts, exposing internal errors to clients, not validating inputs, missing CORS configuration.

Standards & RFCs

Related Terms