HTTP方法选型疑问：为何使用POST/DELETE而非PUT/GET？

Great question—this cuts right to the difference between what you can technically do with HTTP and what you should do to build maintainable, predictable APIs. Let’s break this down:

First: Semantics > Technical Feasibility #

HTTP verbs aren’t just arbitrary commands—they’re a shared language. When you send a GET request, every developer, server, and caching layer expects it to only retrieve data (no side effects). Using GET to delete a resource might work technically, but it breaks that unwritten contract:

• A browser might cache that GET request, leading to stale data for users.
• Someone bookmarking that URL could accidentally trigger a deletion later.
• Tools like API docs or monitoring systems will misinterpret the request’s purpose.

The same logic applies to PUT vs POST:

• PUT is for upserts where you control the resource ID (e.g., PUT /users/123 to create or update user 123). It’s idempotent—sending it 10 times gives the same result as once.
• POST is for creating resources where the server generates the ID (e.g., POST /users to make a new user, and the server returns /users/456). It’s non-idempotent—each request can create a new unique resource (like a new order or comment).

Why Use DELETE Instead of Other Verbs to Remove Resources? #

DELETE has a clear, unambiguous semantic: remove this specific resource. Here’s why that matters:

1. Idempotency: Sending DELETE /users/123 once deletes the user; sending it again returns a 404 (no further side effects). If you used POST to delete, you’d have to handle duplicate requests carefully to avoid errors or unintended behavior.
2. Server & Tooling Support: Most API frameworks have built-in handling for DELETE—like restricting it to authorized users, or logging deletion events separately. Tools like Postman or Swagger will automatically recognize it as a delete operation, making your API easier to use.
3. Clear Intent: Other developers reading your code or API docs don’t have to guess what the request does. DELETE /users/123 is instantly understandable, whereas POST /users/123/delete adds unnecessary complexity.

Why Use POST When PUT Can Create/Update? #

PUT requires you to know the resource’s URI upfront. That works great if you’re creating a resource with a known ID (like importing data where you control the IDs), but most of the time, you want the server to generate the unique identifier for you. That’s where POST shines:

• When you send POST /articles, the server creates the article, assigns it an ID (like 101), and returns the new URI /articles/101. You couldn’t do this with PUT because you don’t know the ID before creating the resource.
• POST is also used for non-idempotent actions that don’t map neatly to CRUD—like triggering a payment process, sending an email, or running a report. These actions aren’t creating or updating a single resource, so PUT doesn’t fit.

Wrapping Up #

At the end of the day, HTTP verbs are about communication—both between your client and server, and between you and other developers. Using the right verb makes your API more predictable, easier to debug, and compliant with web standards. Just because you can hack a GET request to delete data doesn’t mean you should!

内容的提问来源于stack exchange，提问作者Wasim Kukwa