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 \"deactivate

Answer 1

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"}

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.

Answer 3

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).