Frontend Fundamentals

Frontend Fundamentals 2: Understanding HTTP Requests and Responses

The internet is powered by HTTP (HyperText Transfer Protocol), which defines how clients like browsers communicate with web servers. When you open a website or use an API, your browser sends HTTP requests to servers, which respond accordingly. Understanding the types of HTTP requests, how servers respond, and the meaning of status codes and headers can deepen your knowledge of how the web works.

HTTP Request Methods: What Do They Mean?

HTTP methods tell the server what action the client wants to perform on a resource.

Common HTTP Methods

  • GET
    Retrieves data from the server. The response includes the requested resource’s data.
    Use case: Loading a webpage or fetching data from an API.
  • HEAD
    Similar to GET, but only retrieves the headers of the response — no response body.
    Use case: Checking if a resource exists or if it has changed, without downloading the entire content.
  • POST
    Sends data to the server, typically to create a new resource.
    Use case: Submitting a form to create a new user or uploading a file.
  • PUT
    Sends data to the server to update an existing resource or create it if it doesn’t exist.
    Use case: Updating a user profile or replacing a document.
  • DELETE
    Deletes the resource identified by a URL.
    Use case: Removing a user or deleting a file.

Difference between POST and PUT

One common question that often comes up when discussing HTTP methods is: what’s the difference between POST and PUT? The information below provides a clear comparison of the key differences between them.

  • Idempotency
    POST is not idempotent. Sending the same POST request multiple times can result in multiple resources being created. PUT is Idempotent. Sending the same PUT request multiple times will result in the same resource state. The first request may create the resource, but subsequent requests will update it to the same state.
  • Resource Identification
    In a POST request, the server is responsible for generating the resource’s URL (or identifier). The client does not specify the exact location where the new resource will be created. In contrast, with a PUT request, the client specifies the exact URL of the resource. The client sends the resource to a known location, either to create it with a specific identifier or to update an existing one.
  • Use Cases
    Typical use cases for POST include creating new user accounts, submitting form data, uploading files, and initiating processes such as sending emails or starting background jobs. PUT is commonly used for updating existing records like user profiles, replacing entire documents, syncing data between systems, or creating resources with specific, client-defined identifiers such as a user ID or product code.

Difference between GET and HEAD

Another important difference we should know is the one between GET and HEAD.

The GET method is used to retrieve data from a server. It returns the full response, including both the headers and the response body—this body contains the actual content such as HTML pages, JSON data, images, or other media. Since GET is idempotent and safe, it’s ideal for fetching data without making any changes on the server. Common use cases include retrieving web pages, accessing images or videos, and calling API endpoints to display information.

In contrast, the HEAD method works just like GET, but it only returns the headers—no body content is included. This makes HEAD useful for quick checks, such as verifying if a resource exists, checking if it has changed.

HTTP Response Status Codes: What Do They Tell Us?

When a server responds, it sends a status code indicating the outcome of the request. These codes are grouped by categories:

CategoryRangeMeaning
Informational1xxRequest received, continuing process
Success2xxRequest succeeded
Redirection3xxFurther action needed to complete request
Client Error4xxError caused by the client
Server Error5xxError caused by the server

Common Status Codes

  • 200 OK
    Request succeeded, and the response contains the requested data.
  • 404 Not Found
    The requested resource does not exist on the server.
  • 400 Bad Request
    The request could not be understood by the server due to malformed syntax.
  • 500 Internal Server Error
    The server encountered an unexpected condition preventing it from fulfilling the request.
  • 505 HTTP Version Not Supported
    The server does not support the HTTP protocol version used in the request.

HTTP Headers: The Metadata of Requests and Responses

Headers carry important information about the request or response.

Common Request Headers

  • Host: Specifies the domain name of the server (e.g., www.example.com).
  • Connection: Controls whether the network connection stays open after the current transaction (close or keep-alive).
  • User-Agent: Identifies the client software (e.g., browser type/version).
  • Accept-Language: Preferred language(s) for the response.
  • Accept: Types of content the client can process (e.g., text/html, application/json).
  • DNT (Do Not Track): Indicates the user’s tracking preference (1 means “do not track”).

Common Response Headers

  • Connection: Indicates if the server will close the connection after the response.
  • Date: When the response was generated.
  • Server: Server software details.
  • Last-Modified: Date when the resource was last changed.
  • Content-Length: Size of the response body in bytes.
  • Content-Type: MIME type of the returned content (e.g., text/html; charset=UTF-8).
  • Cache-Control: Controls caching policies (e.g., no-cache, max-age=3600).
  • ETag: Identifier for a specific version of the resource, used to validate caches.
  • Transfer-Encoding: Specifies how the message body is encoded (e.g., chunked).
  • X-Frame-Options: Security header that controls whether the page can be embedded in frames.

Cache-Control Directives

  • must-revalidate: Caches must verify with the server before using stale resources.
  • no-cache: Resources can be cached but must be revalidated before use.
  • no-store: Do not cache this resource at all (useful for sensitive data).
  • public / private: Defines whether resources can be cached by any cache or only browsers.
  • max-age=<seconds>: Defines how long the resource is considered fresh.

Understanding HTTP request methods, status codes, and headers is essential for web developers and anyone interested in how the web works under the hood. It empowers you to debug issues, optimize performance, and design better APIs.

Leave a Reply

Your email address will not be published. Required fields are marked *