Mastering HTTP Methods: Actions & Intents

This article had its first draft written by AI, then got the “human touch” to make sure everything’s clear, correct, and worth your time.

1. The Hook and Introduction

Imagine you walk into a massive public library. You interact with the librarian using a very specific set of commands:

• “Can I read this book?”
• “I’d like to add this new book to the catalog.”
• “I need to replace my damaged copy with this pristine one.”
• “Please destroy these old, outdated magazines.”

You wouldn’t ask the librarian to “destroy” a book when you just want to read it. The action you use dictates the intent of your request.

In the world of web development, HTTP Methods (often called HTTP Verbs) are those exact commands. They tell the server precisely what you intend to do with a specific resource.

---

2. The Core Properties of HTTP Methods

Before we look at the specific verbs, you need to understand three critical properties that govern how these methods behave.

1. Safe: A method is “safe” if it doesn’t change the state of the server. It’s read-only.
2. Idempotent: A method is “idempotent” if executing it once has the exact same effect on the server as executing it 100 times in a row.
3. Cacheable: Can the response to this method be stored and reused to speed up future requests?

Knowing these properties is the secret to building robust, predictable APIs.

---

3. The “Big Five”: Mapping to CRUD

In modern RESTful API design, HTTP methods map almost perfectly to CRUD (Create, Read, Update, Delete) database operations. Let’s break down the “Big Five”.

GET (Read)

• Intent: Retrieve a resource.
• Properties: Safe, Idempotent, Cacheable.
• Usage: When you open a website, your browser sends a GET request for the HTML. It shouldn’t change anything on the server.

POST (Create)

• Intent: Submit new data to the server to create a new resource or trigger an action.
• Properties: NOT Safe, NOT Idempotent.
• Usage: Submitting a sign-up form. If you hit “submit” twice, you might accidentally create two accounts (which is why it is not idempotent).

PUT (Update/Replace)

• Intent: Completely replace an existing resource. If it doesn’t exist, it can sometimes create it.
• Properties: NOT Safe, Idempotent.
• Usage: Updating a user profile. Sending the exact same updated profile 10 times results in the same final state.

PATCH (Partial Update)

• Intent: Apply partial modifications to a resource.
• Properties: NOT Safe, NOT Idempotent (though it can be designed to be).
• Usage: Updating just the user’s email address, rather than sending the entire profile object again.

DELETE (Delete)

• Intent: Remove a specific resource.
• Properties: NOT Safe, Idempotent.
• Usage: Deleting a tweet. Deleting it once removes it. Telling the server to delete that same (already deleted) tweet 10 more times won’t change the state of the database further.

---

4. The Problem: “POST Everything” Antipattern

When developers first learn HTTP, a common mistake is treating the protocol purely as a tunnel, wrapping every single request inside a POST.

// The "POST Everything" Antipattern
fetch('/api/users/delete', {
  method: 'POST', // Why use POST to delete?
  body: JSON.stringify({ id: 123 })
});

While this technically works, it destroys the semantics of the web.

---

5. The Solution: Semantic Method Usage

By using the correct HTTP method, your code becomes self-documenting, predictable, and leverages built-in browser and network optimizations.

// Semantic HTTP Usage
fetch('/api/users/123', {
  method: 'DELETE' // Clear intent, relies on URL for resource targeting
});

---

6. Developer Context: Why Should You Care?

As a software developer, adhering to strict HTTP method semantics provides massive architectural benefits:

1. Caching: CDNs and browsers automatically know they can aggressively cache GET requests, saving you server costs and speeding up load times. They know never to cache a POST request.
2. Retry Logic: If a mobile app loses connection during an idempotent request (PUT, DELETE), the client can safely automatically retry the request in the background without fear of duplicating data.
3. API Standards: It allows frontend developers, backend developers, and automated tools (like Swagger/OpenAPI) to understand your API without reading lines of custom documentation.

---

7. Advantages & Disadvantages of Strict Method Semantics

Advantages

• Self-Documenting API: The URL and Method alone tell you exactly what is happening.
• Network Optimization: Leverages browser and proxy caching natively.
• Safety: Prevents accidental data duplication via idempotency.

Disadvantages

• Learning Curve: Requires developers to understand the subtle differences (e.g., PUT vs. PATCH).
• Firewall Restrictions: Some extremely restrictive corporate firewalls or old proxies block PUT and DELETE requests, though this is rare today.

---

8. Conclusion

HTTP methods are the verbs of the web. Using them correctly is the foundation of good API design.

• GET is for reading (Safe & Idempotent).
• POST is for creating or processing (Not Safe, Not Idempotent).
• PUT is for full replacement (Not Safe, Idempotent).
• PATCH is for partial updates.
• DELETE is for removal (Not Safe, Idempotent).

Pro Tip: If you find yourself putting verbs in your URLs (e.g., /getUser or /deleteUser), you are likely ignoring HTTP methods. Let the method be the verb, and let the URL be the noun (e.g., GET /user).

Next Up

We know where the resource is, and what we want to do with it. But how do we pass metadata? How do we say “I want this data, but only in JSON format”? In Part 3 of this series, we will dive into the unsung heroes of the web: HTTP Headers.

---

GitHub Example

To truly master HTTP, you need to experiment with it. I’m building an interactive learning portal where you can visually explore HTTP methods, requests, responses, and core concepts directly in your browser. You can use the portal live or check out the source code:

• Interactive Portal: mcakar-dev.github.io/learn-http
• GitHub Repository: mcakar-dev/learn-http

References

• MDN Web Docs: HTTP request methods
• RESTful API Design Rules