2 posts tagged with "backend"

Note: These are notes from HTTP lecture/video by Sriniously : https://youtu.be/a3C1DMswClQ?si=VkYrm___9JAlL3n0

1. Core Principles of HTTP​

HTTP (Hypertext Transfer Protocol) is an application-layer protocol (Layer 7 in the OSI model) used by clients and servers to communicate. It is built on two fundamental ideas:

• Statelessness: The server retains no memory of past interactions. Every request is entirely self-contained and must include all the necessary information (like authentication tokens or cookies) for the server to process it.
  • Benefits: This simplifies server architecture and improves scalability, because a single server doesn't need to keep track of user sessions, and a server crash won't destroy a client's state.
• Client-Server Model: Communication is always initiated by the client (e.g., a web browser) to request resources or actions, and the server waits for these requests to process and respond.

2. Transport Protocol & HTTP Versions​

HTTP relies on a reliable, connection-based transport protocol, almost universally TCP (Transmission Control Protocol). Over the years, HTTP has evolved to improve how these TCP connections are handled:

• HTTP 1.0: Opened a new TCP connection for every single request and response, which was highly inefficient and slow.
• HTTP 1.1: Introduced persistent connections (keep-alive) as the default, allowing multiple requests to be sent over a single reused connection.
• HTTP 2.0: Introduced multiplexing (multiple requests/responses concurrently on one connection), binary framing, header compression, and server push.
• HTTP 3.0: Replaced TCP with QUIC (built over UDP) to establish faster connections and handle packet loss better, eliminating head-of-line blocking.

3. Anatomy of HTTP Messages​

Client-server communication happens via structured text messages.

• Request Message (Client to Server): Contains a Request Method (e.g., GET/POST), the Resource URL, the HTTP version, Host domain, Headers, a blank line, and an optional Request Body.
• Response Message (Server to Client): Contains the HTTP version, a Status Code (e.g., 200), a Status Value (e.g., OK), Headers, a blank line, and the Response Body.

4. HTTP Headers​

Headers are key-value pairs that act as metadata for the package being transmitted, allowing the system to be highly extensible and act as a "remote control" to dictate server behavior.

• Request Headers: Sent by the client to provide context (e.g., User-Agent identifies the browser, Authorization sends credentials).
• General Headers: Apply to both requests and responses (e.g., Date, Connection, Cache-Control).
• Representation Headers: Describe the message body (e.g., Content-Type for media format like JSON/HTML, Content-Length for byte size, Content-Encoding for gzip compression).
• Security Headers: Protect against attacks (e.g., Strict-Transport-Security forces HTTPS, Content-Security-Policy prevents cross-site scripting, Set-Cookie with HTTP-only flags).

5. HTTP Methods and Idempotency​

Methods define the semantic intent of the client's request.

• GET: Fetches data from the server without modifying anything.
• POST: Submits new data to the server (includes a request body).
• PATCH: Partially updates an existing resource.
• PUT: Completely replaces an existing resource with the provided body.
• DELETE: Removes a resource.
• OPTIONS: Inquires about the server's capabilities (used heavily in CORS).

Idempotency is a crucial concept here:

• Idempotent Methods: Can be executed multiple times and yield the exact same result on the server state (e.g., GET, PUT, DELETE).
• Non-Idempotent Methods: Running them multiple times creates different results (e.g., submitting a POST request twice creates two separate resources).

6. Cross-Origin Resource Sharing (CORS)​

Browsers enforce a Same-Origin Policy, blocking web apps from making requests to different domains (origins). CORS is a security mechanism to bypass this safely.

• Simple Requests: (Usually GET or POST with standard headers/content types). The browser automatically adds an Origin header. If the server allows the request, it replies with the Access-Control-Allow-Origin header containing the client's domain (or a * wildcard). If missing, the browser blocks the response.
• Pre-flight Requests: Triggered if a request uses a non-simple method (PUT/DELETE), requires authorization headers, or uses a application/json content type.
  • The browser first fires an OPTIONS request asking the server if the route supports the intended method and headers.
  • The server replies with a 204 No Content status, explicitly listing allowed origins, methods, headers, and a max-age to cache this configuration.
  • If successful, the browser then sends the actual, original request.

7. Standardized Status Codes​

Status codes are three-digit numbers that act as a universal language to indicate the outcome of a request.

• 1xx (Informational): Indicates headers received; client can proceed (e.g., 100 Continue for large uploads).
• 2xx (Success):
  • 200 OK: Successful operation.
  • 201 Created: Usually follows a POST request.
  • 204 No Content: Successful, but no body to return (used in OPTIONS or DELETE).
• 3xx (Redirection):
  • 301 Moved Permanently: The resource has a new URL.
  • 302 Found/Temporary Redirect: Temporarily forward to a new route.
  • 304 Not Modified: Tells the client to use its locally cached version.
• 4xx (Client Errors):
  • 400 Bad Request: Invalid data format sent by client.
  • 401 Unauthorized: Missing or invalid authentication token.
  • 403 Forbidden: Authenticated, but lacks necessary permissions.
  • 404 Not Found: Incorrect URL or deleted resource.
  • 405 Method Not Allowed: Using the wrong method for a route.
  • 409 Conflict: Business logic violation (e.g., duplicate username).
  • 429 Too Many Requests: Client has hit rate limits.
• 5xx (Server Errors):
  • 500 Internal Server Error: An unhandled exception crashed the server.
  • 501 Not Implemented: Feature not yet supported.
  • 502 Bad Gateway / 504 Gateway Timeout: Issues originating from proxies or load balancers failing to reach upstream servers.
  • 503 Service Unavailable: Server down or under maintenance.

8. HTTP Caching​

Caching reuses previously downloaded responses to save bandwidth and load times.

• When a client first fetches a resource, the server responds with the payload alongside three headers: Cache-Control (sets max duration), ETag (a unique hash of the payload), and Last-Modified.
• On subsequent requests, the client sends conditional headers: If-None-Match (carrying the ETag) or If-Modified-Since.
• If the data on the server hasn't changed, the server saves bandwidth by sending an empty 304 Not Modified response, instructing the browser to use its cached copy. If it has changed, it sends a 200 OK with the new data and a new ETag.

9. Content Negotiation and Compression​

Clients and servers can negotiate the best format to exchange data.

• The client sends preferences via Accept (e.g., application/json vs application/xml), Accept-Language (e.g., en vs es), and Accept-Encoding (e.g., gzip).
• The server responds with the appropriate format.
• Compression: By negotiating an encoding like gzip, a server can drastically compress text responses (e.g., shrinking a 26MB JSON payload down to 3.8MB) to save massive amounts of network bandwidth.

10. Handling Large Data Transfers​

• Large Client Uploads (Images/Video): Standard JSON is terrible for binary data. Instead, clients use a multipart/form-data request. This breaks the file into chunks separated by a unique string delimiter defined in the boundary header.
• Large Server Downloads: To prevent timing out, the server streams the file in chunks using Content-Type: text/event-stream and Connection: keep-alive. The browser continually appends these chunks until the transfer finishes.

11. Security (SSL/TLS & HTTPS)​

• TLS (Transport Layer Security): The modern, secure replacement for the outdated SSL protocol.
• It encrypts data in transit to prevent interception (eavesdropping) or tampering, utilizing certificates to verify the server's identity.
• HTTPS: Simply the standard HTTP protocol wrapped inside a secure TLS connection.

Note: These are notes from Routing lecture/video by Sriniously : https://youtu.be/SubuU1iOC2s?si=Rq3nCiC4bbwIVXsI

1. What is Routing?​

• The "What" vs. The "Where": In a backend system, HTTP methods (like GET, POST, DELETE) express the what or the intent of a request (e.g., fetching or adding data). Routing expresses the where—the specific resource or destination you want to apply that action to.
• Definition: Routing is the process of mapping a combination of an HTTP method and a URL path to a specific server-side Handler (a set of instructions or business logic).
• Uniqueness: The server concatenates the HTTP method and the route to form a unique key. For example, a GET request to /api/books and a POST request to /api/books will trigger completely different logic in the server without clashing.

2. Types of Routes​

There are two primary ways to structure a route path:

• Static Routes: These are constant strings that do not contain any variable parameters. For example, /api/books will always stay consistent and point to the same general resource.
• Dynamic Routes: These include variable slots within the URL that the server can extract as data. In most backend frameworks (like Node.js, Python, or Go), these are denoted by a colon, such as /api/users/:id. If a client requests /api/users/123, the server extracts "123" as the ID to fetch that specific user's data.

3. Path Parameters vs. Query Parameters​

When sending data through a URL, backend engineers use two distinct types of parameters:

• Path Parameters (Route Parameters): These are the variables placed directly inside the route's path, right after a forward slash / (e.g., the 123 in /api/users/123). They are used to express semantic meaning, specifically identifying a unique resource.
• Query Parameters: Because GET requests do not have a data body, query parameters are used to send key-value pairs of metadata to the server.
  • Syntax: They are attached to the end of the route after a question mark ? (e.g., /api/search?query=some+value).
  • Use Cases: They are heavily used for pagination (e.g., page=2&limit=20), filtering user-defined values, or determining sorting orders (ascending/descending).

4. Nested Routing​

Nested routing is a standard REST API practice used to express a hierarchy between different resources.

• Semantic Hierarchy: By nesting paths, you create a highly readable, semantic expression of what data you want.
• Example Workflow:
  • /api/users: Fetches a list of all users.
  • /api/users/123: Goes one level deep to fetch a specific user.
  • /api/users/123/posts: Goes another level deep to fetch all posts created by user 123.
  • /api/users/123/posts/456: Fetches one highly specific post (ID 456) belonging to that specific user.

5. Route Versioning and Deprecation​

As applications grow, business requirements change, which might require you to completely alter the format of the data your API returns (e.g., switching the key name to title).

• The Problem: If you change the response format on a live route, you will break the frontend application (like an iOS or React app) currently relying on it.
• The Solution (Versioning): Engineers add version numbers to routes, such as /api/v1/products and /api/v2/products.
• Deprecation: This allows the server to simultaneously support both the old and new data structures. It provides frontend engineers a safe window of time to migrate their code to v2 before the backend team officially deprecates and removes v1.

6. Catch-All Routes​

• Purpose: A catch-all route acts as a safety net for invalid requests.
• How it Works: It is placed at the very end of the server's routing logic, often using a wildcard syntax like /*. If a request trickles down through all the previous route matching algorithms without finding a match, it hits the catch-all.
• Benefit: Instead of the server defaulting to a broken or null response, the catch-all handler cleanly returns a user-friendly "Route Not Found" (404) message to the client.