Why Senior Engineers Disagree About HTTP methods (GET, POST, etc.)

To an outsider, the basic tools of the web seem simple. But ask two senior software engineers about the "right" way to use HTTP methods like GET and POST, and you might spark a surprisingly passionate debate. Here’s what’s really going on.

First, The Basics

HTTP methods are the verbs of the internet, telling a server what action a client wants to perform on a resource. Most developers are familiar with the core group, which maps to the common acronym CRUD (Create, Read, Update, Delete). GET retrieves data, like loading a webpage. POST creates a new resource, like submitting a form. PUT is meant to update or replace an entire resource, while PATCH is for partial updates. And DELETE, as you can guess, removes a resource. On the surface, these seem like clear, distinct instructions. The trouble starts when theory meets the messy reality of software development.

The Two Schools of Thought: Purists vs. Pragmatists

The disagreement boils down to a philosophical divide between two camps: the Purists and the Pragmatists. The Purists argue for a strict interpretation of REST (Representational State Transfer), the architectural style that governs how these methods should work. For them, using each verb precisely as intended creates a clean, predictable, and self-documenting system. The Pragmatists, on the other hand, favor whatever is most practical, efficient, and gets the job done with the least amount of friction. They argue that strict adherence to REST principles can sometimes be more trouble than it's worth.

The Core of the Conflict: Idempotency

A key concept at the heart of this debate is "idempotency." An operation is idempotent if you can do it multiple times and get the same result as doing it just once. Think of an elevator button: pressing it once calls the elevator, and pressing it ten more times doesn't call ten more elevators. According to the official rules, GET, PUT, and DELETE are idempotent. If you request the same data with GET twice, nothing changes. If you use PUT to update a user's name to "Alex," running it again won't cause any further change. But POST is not idempotent; submitting a form twice often means creating two separate entries. This distinction has huge real-world implications for building reliable systems, especially when network errors cause clients to automatically retry requests.

The PUT vs. PATCH Battleground

Nowhere is the debate more visible than in the endless discussion over PUT versus PATCH. According to the specification, PUT is for replacing a resource in its entirety. If a user has a profile with ten fields and you want to update their email, a PUT request would require you to send all ten fields, with the new email included. A PATCH request, however, is designed for partial updates; you would only need to send the new email address. The Pragmatist might argue that implementing PATCH is more complex, as the server needs logic to merge changes. The Purist would counter that using PUT for a small change is inefficient and risks accidentally nullifying other fields if the client doesn't send the full resource.

So, Who Is Right?

The truth is, there's no single right answer, which is precisely why senior engineers still debate it. The disagreement isn't about the basic definitions but about the tradeoffs between architectural purity and practical application. A Purist approach often leads to APIs that are more consistent and easier for new developers to understand over the long term. A Pragmatic approach can lead to faster development and simpler solutions for specific problems, even if it bends the rules. Often, the most senior engineers are those who understand the principles so deeply that they know when and why it's acceptable to break them. They recognize that the goal isn't to win a technical argument but to build a system that works for its intended purpose.