HTTP Request Types & Headers Reference

Understanding HTTP Requests in Depth

HTTP requests are the foundation of communication on the web. Every time you click a link, submit a form, or an application fetches data, HTTP requests travel from client to server. Understanding the anatomy of these requests—the methods, headers, body formats, and authentication mechanisms—is essential for web developers, API designers, and anyone working with web technologies.

A complete understanding of HTTP requests enables you to debug network issues, optimize performance, implement security correctly, and design APIs that are intuitive and robust. This guide covers the structure of HTTP requests in detail, from the request line to the body.

The Request Line

Every HTTP request starts with a request line containing three components: the HTTP method, the request URI (path), and the HTTP version. For example, "GET /api/users HTTP/1.1" requests the /api/users resource using the GET method and HTTP version 1.1.

The method indicates the intended action: GET for retrieval, POST for creation, PUT/PATCH for updates, DELETE for removal. The path identifies the resource, possibly including query parameters for filtering or pagination. The version is typically HTTP/1.1 or HTTP/2, though HTTP/3 is emerging.

Request Headers Explained

Headers provide metadata about the request—who is making it, what format they expect, how to authenticate, and more. Headers are key-value pairs, case-insensitive in HTTP/1.1 (but conventionally capitalized) and lowercase in HTTP/2.

Content-Type tells the server how to parse the request body. "application/json" means JSON data; "multipart/form-data" means form data possibly including files. Without the correct Content-Type, servers may reject or misinterpret the request.

Accept tells the server what response formats the client can handle. "Accept: application/json" requests JSON responses; "Accept: text/html" requests HTML. Servers should respect this header through content negotiation, returning the requested format or an error if unable.

Authorization carries credentials. Bearer tokens (JWTs) are common for API authentication. Basic authentication encodes username:password in Base64 (never use over plain HTTP). OAuth 2.0 flows result in bearer tokens sent in this header.

Cache-Control requests specific caching behavior. "no-cache" requires validation before using cached responses. "no-store" prevents caching entirely. These are requests to the cache, not commands—caches may not always comply.

Request Body Formats

The request body carries data for methods like POST, PUT, and PATCH. The Content-Type header specifies the format. The most common formats each have specific use cases.

JSON (application/json) is the standard for modern APIs. It is text-based, human-readable, and has first-class support in JavaScript. Nearly all REST APIs expect and return JSON. Ensure proper Content-Type and valid JSON syntax.

Form URL Encoded (application/x-www-form-urlencoded) is the traditional HTML form format. Data is encoded as key=value pairs separated by ampersands, with special characters URL-encoded. Simple and works without JavaScript but less flexible than JSON.

Multipart Form Data (multipart/form-data) supports file uploads. Each field is sent in its own section with a boundary separator. Files can be sent as binary data. Required when uploading files; also works for non-file data but is more verbose than URL encoding.

Raw/Text (text/plain, application/xml, etc.) sends raw content. XML was common before JSON dominated. Some specialized APIs use custom formats. GraphQL queries are often sent as raw text (application/graphql) or in JSON.

Authentication Deep Dive

Bearer Tokens are the most common API authentication method. After logging in, clients receive a token (often a JWT) that they include in subsequent requests. Tokens are self-contained (JWTs contain user info and expiration) or opaque (requiring server lookup).

Basic Authentication sends credentials with every request, Base64-encoded (NOT encrypted). It is only safe over HTTPS. While simple, it exposes credentials on every request, making secure storage and transport critical.

API Keys identify the calling application rather than a user. They are often sent as a header (X-API-Key) or query parameter. API keys enable rate limiting and access control at the application level.

OAuth 2.0 is a full authentication framework for third-party access. Users authorize applications through a provider (Google, GitHub). Applications receive tokens without ever seeing user passwords. Complex but secure and widely supported.

CORS and Cross-Origin Requests

Browsers enforce same-origin policy: scripts can only make requests to their own origin by default. Cross-Origin Resource Sharing (CORS) allows servers to specify which origins can access their resources.

Simple requests (GET, POST with simple content types) are sent directly with an Origin header. The server's response includes Access-Control-Allow-Origin to indicate whether the browser should allow the script to read the response.

Complex requests (PUT, DELETE, custom headers) trigger a preflight OPTIONS request first. The server responds with allowed methods, headers, and origins. Only if the preflight succeeds does the browser send the actual request.

Request Optimization

Compression: The Accept-Encoding header (gzip, deflate, br) tells servers the client supports compressed responses. For request bodies, Content-Encoding indicates the body is compressed (less common but supported).

Conditional Requests: If-None-Match and If-Modified-Since headers enable caching. The server can respond with 304 Not Modified if the content has not changed, saving bandwidth.

Batching: Multiple operations in one request reduce network overhead. GraphQL does this naturally. REST APIs might support batch endpoints (/batch accepting an array of operations).

Debugging HTTP Requests

Browser developer tools show all network requests with headers, bodies, timing, and responses. The cURL command-line tool can recreate requests for testing. Postman and similar apps provide friendly interfaces for API exploration.

Common issues include incorrect Content-Type (server cannot parse body), missing Authorization (401 Unauthorized), CORS errors (browser blocking cross-origin), and malformed JSON (parsing failure on server).