Skip to main content

HTTP Methods

HTTP (Hypertext Transfer Protocol) is the backbone of the World Wide Web, governing how data is transmitted between clients and servers. At the core of HTTP's communication model lies the use of HTTP Methods, or verbs, which prescribe the actions to be taken on web resources. In this comprehensive article, let's delve into the origins of these verbs, their profound significance in the HTTP protocol, and how they have evolved, while also touching on their technical intricacies.

The Origins of HTTP Verbs/Methods​

HTTP traces its origins back to the early 1990s when it was conceptualized by Tim Berners-Lee and developed by his team at CERN. The first documented HTTP specification emerged in 1991, introducing a set of methods, now known as HTTP verbs, that facilitate the retrieval and manipulation of resources. These methods laid the foundation for the modern web.

While HTTP's history doesn't record any tales of naming, it's worth noting that the naming of these verbs was driven by a need for simplicity and clarity in web communication. The initial developers aimed to create a system that was easy to understand and use for both humans and machines. They may have borrowed concepts from many existing protocols, e.g. FTP which had get, put and delete commands. In the following you can see how these were matured over time.

  • HTTP 0.9 had a single method: GET.
  • HTTP 1.0 had the methods: GET, HEAD, and POST.
  • HTTP 1.1, the current version, has the methods: GET, HEAD, POST, OPTIONS, PUT, DELETE, TRACE, and CONNECT.

Significance in the HTTP Protocol​

Most common HTTP Verbs​

  • GET: The GET method is used to retrieve data from a specified resource, and it is one of the most widely used HTTP verbs. It employs a simple request-response model. A client issues a GET request to a server, which then responds by providing the requested data. GET should ideally have no side effects on the server, meaning it should only retrieve information without causing any changes to the resource.

    Example: When you enter a web address in your browser, it sends a GET request to the server to fetch the web page for display.

  • POST: The POST is the method used to submit data to be processed to a specified resource. Unlike GET, POST often leads to state changes or data creation on the server. It allows clients to send data to the server for further processing, such as submitting a form.

    Example: When you fill out a contact form on a website and click 'Submit,' your data is sent to the server using a POST request, which then processes and stores it.

  • PUT: The PUT method instructs the server to store the enclosed entity at a specified location. It is commonly used to update a resource, but it can also create a new resource if it doesn't already exist. PUT requests are idempotent, meaning multiple identical requests will have the same effect as a single request.

    Example: In a content management system, the PUT request is used to update an existing blog post.

  • DELETE: The DELETE is self-explanatory; it is used to request the removal of a resource. When a client sends a DELETE request, it instructs the server to delete the specified resource.

    Example: When you delete an email in your inbox, the email client sends a DELETE request to the server to remove that email.

  • PATCH: PATCH is used to apply partial modifications to a resource. Unlike PUT, which typically replaces an entire resource, PATCH selectively updates only the specified fields of a resource.

    Example: In an e-commerce system, a PATCH request could be used to modify the quantity of an item in a shopping cart.

Lesser-Known HTTP Verbs​

In addition to the commonly used HTTP verbs like above, there are some lesser-known HTTP verbs that play niche but vital roles in specific scenarios:

  • HEAD: The HEAD method is similar to GET but is used to request the headers of a resource without the actual content. This can be useful for checking resource metadata or determining if a resource has been modified since a certain date without downloading the full content. It's often used to reduce bandwidth usage.

  • OPTIONS: The OPTIONS method is used to request information about the communication options available for a target resource. It can help a client understand which HTTP methods are supported for a resource, what headers are allowed, or other capabilities of the server. This is particularly useful in cross-origin requests for security considerations.

  • CONNECT: The CONNECT method is typically used with a proxy that can dynamically switch to being a tunnel. It is used to establish a network connection to a resource. CONNECT is crucial for secure, encrypted connections, such as those required for HTTPS.

  • TRACE: The TRACE method is mostly used for diagnostic purposes. When a client sends a TRACE request to a server, it should receive the same request back. This allows the client to see what changes might have been made to the request by intermediaries, like proxies, along the way.

  • PURGE: Although not a standard HTTP verb, PURGE is sometimes used in web caching systems to request the removal of a resource from a cache. It's often employed by content delivery networks and reverse proxies.

These HTTP verbs form the basis of the client-server communication model and dictate how web applications interact with resources. They are the fundamental building blocks that enable web services, RESTful APIs, and other web-related functionalities.

Evolving with HTTP/2​

HTTP/2, a significant evolution of the HTTP protocol, introduced several game-changing improvements. While the core HTTP verbs remain unchanged, HTTP/2 focused on optimizing performance and efficiency.

One of the most prominent enhancements in HTTP/2 is multiplexing. Unlike the traditional HTTP/1.1, which used a separate connection for each resource, HTTP/2 allows multiple requests and responses to be sent in parallel over a single TCP connection. This significantly reduces latency and improves page load times. The use of HTTP/2 enhances the way HTTP verbs are utilized by enabling multiple GET requests for various resources to be bundled into one connection.

It's important to understand that HTTP GET and POST requests are still processed as separate and distinct requests, even when multiplexed.

Here's why:

  • Semantics: The semantics of the GET and POST methods are different. GET is used to request data from a resource, while POST is used to submit data to be processed. Merging them into a single request could lead to ambiguity in terms of the intended action.
  • HTTP Standards: The HTTP standards define GET and POST as distinct methods. While HTTP/2 allows for multiplexing, it doesn't alter the fundamental behavior and semantics of these methods.
  • Security and Compatibility: Merging GET and POST requests would introduce complexity and could have security implications. It might also break compatibility with existing web servers and applications that expect requests to conform to the standard semantics.

Web Sockets and Real-Time Communication​

HTTP Verbs do not address the requirements of real-time, bidirectional communication. This is where Web Sockets come into play by providing a mechanism for full-duplex, real-time communication over a single TCP connection, making them ideal for applications that demand low-latency, real-time data exchange.

Web Sockets pivot the request-response model of traditional HTTP. They are not constrained by the typical HTTP verbs. Instead, they establish a persistent connection and facilitate bidirectional communication, allowing data to be sent and received at any time, without the need to initiate a new HTTP request for each interaction. This makes Web Sockets highly suitable for applications like online gaming, chat platforms, financial trading systems, and collaborative tools.

Rest APIs - Architectural Choice​

HTTP verbs play a pivotal role in Representational State Transfer (REST) APIs. Here's an outlook on the role of HTTP verbs in REST APIs:

  • Resource Identification: The URL, combined with the HTTP verb, provides a clear and consistent way to access and manipulate resources.
  • Uniform Semantics (Interface) To Interact With Entities: HTTP verbs are a fundamental part of this uniform interface, providing a limited set of actions that can be performed on resources, making it easier for developers to understand and use APIs.
  • Idempotence: Some HTTP verbs are idempotent, meaning that sending the same request multiple times has the same effect as sending it once. For example, GET and PUT are typically considered idempotent, while POST is not.
  • Self-Descriptive: REST APIs are designed to be self-descriptive. By looking at the HTTP verb and URL, clients and developers can understand the intended action and resource.

In principal, HTTP verbs are the bedrock of web and data communication, dictating how resources are accessed, modified, or deleted. Mastering these fundamental concepts is crucial for application developers in this age.