What is the DELETE method? — HTTP verb: DELETE

The DELETE method

The DELETE method is an HTTP verb used to remove a resource from the server.

Imagine you have a to-do list app. You finished a task and want to remove it permanently: that is what a DELETE request does. You tell the server: "I no longer need this resource. Please remove it."

DELETE in the CRUD family

HTTP verbs map directly to the four fundamental database operations known as CRUD:

Operation	HTTP Verb	Purpose
Create	POST	Add a new resource
Read	GET	Retrieve a resource
Update	PUT / PATCH	Modify an existing resource
Delete	DELETE	Remove a resource

DELETE completes the cycle. Without it, applications could only accumulate data but never clean it up.

How DELETE works

A DELETE request is straightforward:

The client sends a DELETE request to a specific resource URL
The server locates the resource
The server removes it (or marks it as removed)
The server responds with a status code confirming the outcome

DELETE /api/tasks/42 HTTP/1.1
Host: example.com
Authorization: Bearer abc123

Notice there is no request body. Unlike POST, PUT, or PATCH, you do not need to send any data: the URL itself identifies what should be deleted.

Key characteristics

Idempotent

DELETE is idempotent, meaning that sending the same DELETE request multiple times produces the same result as sending it once. The first request deletes the resource. Subsequent requests find that the resource is already gone: the server state does not change further.

This is an important property for network reliability. If a client sends a DELETE request and never receives a response (due to a network timeout), it can safely retry the request without worrying about unintended side effects.

Not safe

In HTTP terminology, a method is "safe" if it does not modify server state. GET and HEAD are safe methods. DELETE is not safe because it changes the server by removing data.

No request body required

The HTTP specification allows a body in DELETE requests, but most servers and frameworks ignore it. The resource to delete is identified entirely by the URL. This keeps DELETE requests simple and predictable.

Real-world examples

You use DELETE operations constantly, even if you do not realize it:

Removing a social media post: DELETE /posts/789
Unsubscribing from a newsletter: DELETE /subscriptions/45
Deleting a user account: DELETE /users/12
Removing an item from a shopping cart: DELETE /cart/items/3
Canceling a pending order: DELETE /orders/101

Every time you click "Delete", "Remove", or "Cancel" in a web application, there is likely a DELETE request being sent behind the scenes.

DELETE vs other methods

Feature	GET	POST	PUT	PATCH	DELETE
Purpose	Read	Create	Replace	Partial update	Remove
Has body?	No	Yes	Yes	Yes	No
Idempotent?	Yes	No	Yes	No	Yes
Safe?	Yes	No	No	No	No
Cacheable?	Yes	No	No	No	No

DELETE shares idempotency with GET and PUT, but unlike GET, it modifies server state.

Summary

Concept	Key Point
Purpose	Remove a resource from the server
CRUD role	The "D" in Create, Read, Update, Delete
Request body	Not required: the URL identifies the resource
Idempotent	Yes: repeating the same request has no additional effect
Safe	No: it modifies server state by removing data
Common use	Delete buttons, remove actions, account cancellation