Web Apps & HTTP Protocol: Architecture, Requests, and Real-World Use

Core Concepts: Web Applications and HTTP Protocol

What is a Web Application?

A web application is a client-server software system where the client (user’s browser) runs on any device, and the server (hosted on a remote machine) processes requests and returns dynamic responses. Unlike traditional desktop apps, web apps rely entirely on HTTP/HTTPS for communication.

flowchart TD
    A["User (Client)"] -->|"HTTP Request"| B["Web Server"]
    B -->|"HTTP Response"| A
    C["Database"] -->|"Data"| B
    D["Business Logic"] -->|"Processes"| B

Key Components:

• Client: Browser (Chrome, Firefox) or mobile app.
• Server: Hosts the app (e.g., IIS, Apache, or ASP.NET Core’s Kestrel).
• HTTP Protocol: Rules for exchanging data (text, JSON, images).
• Dynamic Content: Generated on-the-fly (e.g., eSewa bill payment).

Shows how a user’s request travels to the server and back. (Image: Michel Bakni, CC BY-SA 4.0, via Wikimedia Commons)

HTTP Protocol: The Backbone of Web Communication

HTTP (HyperText Transfer Protocol) is a stateless, text-based protocol for transferring data over the web. It defines:

1. Request-Response Cycle: Client sends a request; server sends a response.
2. Methods (Verbs): GET, POST, PUT, DELETE, HEAD, OPTIONS.
3. Status Codes: 200 OK, 404 Not Found, 500 Server Error.
4. Headers: Metadata (e.g., Content-Type: application/json, Authorization: Bearer token).

HTTP Request/Response Structure

// Example: GET request to fetch user profile
GET /api/user/123 HTTP/1.1
Host: api.esewa.com
Accept: application/json
Authorization: Bearer xyz789

// Example: Server response
HTTP/1.1 200 OK
Content-Type: application/json

{
  "id": 123,
  "name": "John Doe",
  "balance": 5000
}

How HTTP Works: A Step-by-Step Trace

Let’s trace how a Daraz order is processed using HTTP:

1. User Action: You click "Place Order" on Daraz.
2. Client Request:

   POST /checkout HTTP/1.1
   Host: www.daraz.com
   Content-Type: application/json
   {
     "items": [{"productId": 101, "quantity": 2}],
     "shippingAddress": {...}
   }
   

3. Server Processing:
   • Validates the order.
   • Checks inventory (database).
   • Generates an order ID.
4. Server Response:

   HTTP/1.1 201 Created
   Location: /orders/45678
   {
     "orderId": 45678,
     "status": "Processing"
   }
   

5. User Sees: Order confirmation page with orderId=45678.

Why This Matters:

• HTTP ensures statelessness (no server memory of past requests).
• Idempotency: GET /orders/45678 always returns the same data.
• Security: HTTPS encrypts data (e.g., your credit card details on Daraz).

HTTP Methods: What Each Does

Real-World Example:

• Ncell Recharge: POST /recharge (non-idempotent; recharging twice deducts twice).
• NEPSE Stock Data: GET /stocks/NEPSE (idempotent; always returns the same data for a given time).

HTTP Status Codes: What They Mean

State vs. Stateless: Why HTTP is Stateless

• Stateless: Server does not store client data between requests.

  • Pros: Scalable (any server can handle any request), fault-tolerant.
  • Cons: Requires cookies/sessions for user-specific data (e.g., logged-in state).

• Stateful: Server remembers client data (e.g., WebSockets, TCP connections).

  • Used in real-time apps like Pathao’s live ride tracking.

Comparison Table:

In the Real World

1. eSewa Payments:

   • Uses POST /pay with HTTP to process transactions.
   • Why HTTP? Statelessness ensures no payment is lost if a server restarts.
   • Security: HTTPS encrypts card details; 403 Forbidden if fraud detected.

2. Daraz Order Processing:

   • POST /checkout triggers inventory checks via HTTP.
   • Race Condition: If two users POST the same product simultaneously, Daraz uses optimistic concurrency (HTTP 409 Conflict if stock runs out).

3. Ncell’s API:

   • GET /balance fetches user balance (idempotent).
   • POST /recharge deducts money (non-idempotent; retries cause double charges).

Worked Example: HTTP Request for NTC Bill Payment

Scenario: You pay your NTC bill via eSewa.

1. Client Request:

   POST /api/payments HTTP/1.1
   Host: api.esewa.com
   Content-Type: application/json
   Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...
   
   {
     "amount": 500,
     "reference": "NTC123456",
     "userId": "user789"
   }
   

2. Server Response (Success):

   HTTP/1.1 201 Created
   Location: /payments/abc123
   {
     "status": "Processing",
     "transactionId": "abc123",
     "amount": 500
   }
   

3. Server Response (Failure):

   HTTP/1.1 402 Payment Required
   {
     "error": "Insufficient funds",
     "suggestedAction": "Add money to eSewa wallet"
   }
   

Why This Works:

• Idempotency: Retrying POST /payments with the same reference won’t double-charge.
• Atomicity: Either the payment succeeds or fails (no partial transactions).

Common HTTP Headers and Their Uses

Real-World Use:

• Khalti: Uses Authorization: Bearer <token> for secure API calls.
• YouTube: Uses Cache-Control: public, max-age=10800 to cache videos.

Exam Tip

1. HTTP Methods and Status Codes:

   • Memorize the 4 main methods (GET, POST, PUT, DELETE) and their idempotency.
   • Know 3 client errors (400, 401, 404) and 2 server errors (500, 503) with examples.
   • Past Exam Trick: Questions often ask to "differentiate between GET and POST." Use the table above.

2. Real-World Scenarios:

   • Always relate HTTP to eSewa, Daraz, or Ncell in explanations. For example:
     • "Like Daraz’s POST /checkout, HTTP POST is used for creating resources (orders, payments)."
   • For statelessness, say: "HTTP’s statelessness is why eSewa can scale to millions of users without session overload."

3. Diagrams:

   • Draw request/response cycles for any scenario (e.g., NTC bill payment).
   • Label HTTP headers in a table (e.g., Authorization, Content-Type).

4. Common Pitfalls:

   • Don’t confuse PUT (replace) and PATCH (partial update).
   • Don’t say HTTP is stateful—it’s stateless by design (use cookies/sessions for state).
   • For ASP.NET Core exams: Know that GET requests are idempotent, while POST are not.

Visual Summary:

mindmap
  root((HTTP Protocol))
    Request
      Methods["GET, POST, PUT, DELETE"]
      Headers["Content-Type, Authorization"]
    Response
      Status Codes["200, 404, 500"]
      Body["JSON, XML, HTML"]
    Characteristics
      Stateless["No server memory"]
      Text-Based["Plaintext or binary"]
    Real-World
      eSewa["POST /pay"]
      Daraz["GET /products"]
      Ncell["GET /balance"]