Is it okay to use an HTTP DELETE to deactivate a record?

Question

I'm building a RESTful API command to deactivate a user record. Is it kosher to use DELETE to do this or should this be a PUT, since the record is being updated to "deactivated" status? Or is it just a matter of taste?

Gentlemanfarmer

Answer 1

The semantics of DELETE means that you are actually getting rid of the object. What you're doing here seems like a modification of the object's state. In this case a PUT or PATCH would be more appropriate.

It is better to stick with the semantics of uniform interface that you're using (in this case, HTTP verbs). If those match up to what you're actually doing within your app, then there is less confusion. Also, what if you decide later that a DELETE should actually remove a record instead of just marking it "inactive"? Now you've changed the behavior of your API. Also, if you're using DELETE, you're essentially following the "principle of least surprise", which is good for an API. It's better to have a DELETE actually do a delete, rather than just pretending to do so.

On the other hand it is perfectly fine to remove the record from one location and move it elsewhere (from one table to another, for example) if it turns out that you are required to keep the data for historical purposes. In this case, that record should just remain unavailable to future operations (i.e., a GET on the resource should return a 404).

Schiff

Just a small addition: According to RFC-2616 the server may also move the resource to an inaccessible location. At the end a GET on the deleted resource should return a 404 – Ungrounded

@Ungrounded Correct! I mentioned that in my last paragraph. Added the bit about the 404 for additional clarification. – Schiff

Worth adding: If you use a soft-delete deletion technique, DELETE is still appropriate. – Melany

I agree with @ChristoKiwi. Many applications do not physically delete any record in database, but mark IsDeleted column (or similar) as 1. So the whole history of state history is kept. – Electrocute

Answer 2

If after your deactivation operation, the resource is not accessible to the end user any more through "GET" unless it is reactivated again, I do not see a problem using "DELETE". Otherwise, "PUT" is more appropriate.

Embroider

Answer 3

If the resource at the URL you send the DELETE request to is no longer available at that URI, then DELETE is appropriate. If it remains there but changes state, then it is not.

e.g. this is okay (the resource at /friends/bob goes away; a new resource is created at /formerfriends/bob in the process, but that is incidental):

GET /friends/bob => 200 OK
GET /formerfriends/bob => 404 Not Found
DELETE /friends/bob => 204 No Content
GET /friends/bob => 410 Gone
GET /formerfriends/bob => 200 OK

this is not:

GET /friends/bob => 200 OK {"status"="friend"}
DELETE /friends/bob => 204 No Content
GET /friends/bob => 200 OK {"status"="formerfriend"}

something like that would be better handled with PUT or PATCH:

GET /friends/bob => 200 OK {"status"="friend"}
PATCH /friends/bob {"status"="formerfriend"} => 204 No Content
GET /friends/bob => 200 OK {"status"="formerfriend"}

Slattery