What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Use POST when a server should process submitted content according to the target resource’s rules; use PUT when the client knows the target URI and wants to create or replace that resource’s state; use DELETE to remove the association between a URI and its current resource functionality. These distinctions affect which success response to send—and whether a client can safely retry after a timeout.
The controlling definitions are in RFC 9110, HTTP Semantics, especially §§9.2.2 and 9.3.3–9.3.5. Framework routing conventions may shape how an API is implemented, but they do not change the HTTP meaning of these methods.
POST, PUT, and DELETE at a glance
| Method | What the client is asking | Who identifies the target URI? | Idempotent? | Successful response guidance |
|---|---|---|---|---|
POST |
Have the target resource process the request content according to its own semantics. | The client identifies the processing target; the server may choose the URI of a resource created as a result. | Not guaranteed. Repeating a POST can repeat the operation. | Depends on the outcome. For server-selected resource creation, a response commonly identifies the created resource; the exact success status depends on the result. |
PUT |
Create or replace the state of the resource at the target URI using the request representation. | The client supplies the target URI. | Yes, by intended effect. | Use 201 Created if the request successfully creates the resource. For a successful replacement, choose a success response that describes the result. |
DELETE |
Remove the association between the target URI and its current functionality. | The client supplies the target URI. | Yes, by intended effect. | Use 202 Accepted if the action has not yet been enacted, 204 No Content if it has and no further information is supplied, or 200 OK if a response representation describes the status. |
These definitions come from RFC 9110. The table describes HTTP semantics, not a required URL pattern or framework-specific controller design.
When to use POST
POST asks the target resource to process the enclosed representation according to that resource’s own semantics. The server might process form data, append information, or create a related resource. Because the server can select the URI of a newly created resource, POST is the fitting choice when the client does not know or choose that URI.
For example, a client might send a new order to an orders collection. The collection processes the request and can assign the new order its own URI. The key point is not that POST always means “create”; it is that POST delegates processing to the target resource.
When to use PUT
PUT expresses a specific target and replacement intent: the client asks that the state of the resource at the request URI be created or replaced with the state defined by the request representation. Use it when the client knows the resource URI and intends that state-setting operation.
If a successful PUT creates a resource that did not previously exist, RFC 9110 requires the server to report 201 Created. If PUT updates an existing resource, the success response should communicate the result; PUT’s meaning does not require a particular response body.
PUT is idempotent, but that does not mean every response must be identical. The first request might create the resource and return 201 Created, while a later identical request replaces it and returns a different success status. The intended effect on the resource state remains the same.
Rank #3
When to use DELETE—and what it does not promise
DELETE asks the server to remove the association between the target URI and its current functionality. It does not, by itself, promise that every stored representation is securely erased or that storage is physically reclaimed; those are implementation details outside the method’s guarantee.
Choose the success response to match what has happened:
202 Accepted: the request is accepted, but the action is likely to succeed and has not yet been enacted. Do not describe this response as a completed deletion.204 No Content: the action has been enacted and there is no additional information to return.200 OK: the action has been enacted and the response includes a representation describing its status.
A DELETE request body has no generally defined semantics. RFC 9110 advises clients not to send content in a DELETE request unless the origin server has indicated that it supports it. Do not assume intermediaries or other servers understand a private convention for such a body.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Idempotency and safe retries
RFC 9110 §9.2.2 defines idempotency this way: “A request method is considered "idempotent" if the intended effect on the server of multiple identical requests with that method is the same as the effect for a single such request.” PUT and DELETE are idempotent by this definition. The server may still log each request, maintain revision history, or return different responses; those incidental effects do not change the intended effect on the resource.
Recommended Free Tools
Idempotency matters when a client loses the connection or times out and cannot tell whether the server applied a request. A client can generally retry an idempotent PUT or DELETE when it needs to establish the intended state. For a non-idempotent request, RFC 9110 says clients should not automatically retry unless they know the operation is idempotent or can determine that the original request was not applied.
That makes a blind POST retry risky. If the first request reached the server but the response was lost, sending it again may cause processing to happen twice—for example, creating two orders. The HTTP method alone does not give POST an exactly-once guarantee. If an API needs duplicate protection, its contract must define how clients and servers recognize repeated submissions; do not assume that behavior is provided by POST itself.
Quick Recap
Choosing the method for an API operation
- Identify the target. If the client has a specific resource URI and wants its state created or replaced, use PUT. If the client submits content to a resource for processing and the server may choose a resulting URI, use POST.
- State the intended effect. Define what processing, replacement, or removal means for the resource. Avoid choosing a method merely because a framework example uses it for a particular route.
- Match the response to the outcome. A created resource from PUT must return
201 Created. For DELETE, distinguish accepted-but-pending work from an enacted action, then select202,204, or200accordingly. - Plan for uncertain delivery. Assume a client may not receive a response even when the server applied the request. Decide which operations are safe to repeat and document any duplicate-protection behavior relied on for POST.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
