CODEWITHSUNDEEP
restputhttp-delete
abeger
abeger

Reputation: 6866

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

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?

Upvotes: 23

Views: 6305

Answers (4)

tukool
tukool

Reputation: 132

I am not sure if things have changed in the 9+ years since this question last saw activity, but the current reading of the DELETE method indicates times have changed, based on the accepted answer:

The DELETE method requests that the origin server remove the association between the target resource and its current functionality. In effect, this method is similar to the "rm" command in UNIX: it expresses a deletion operation on the URI mapping of the origin server rather than an expectation that the previously associated information be deleted. (emphasis mine).

HTTP request methods are semantic intentions. The intent of DELETE is to remove the association between the URI and the target resource (not "actually get rid of the object" per the accepted answer).

If I receive a DELETE request, regardless of how I remove that association (actually deleting the record or marking it 'inactive/deleted/whatever'), the GET response (which ultimately satisfies the intention) should not return the resource from the requested URI. Does it matter if it physically exists or not?

Based on the current spec, anything that removes the association between the target resource and its associated URI mapping is the intent of the DELETE method.

Upvotes: 0

Nicholas Shanks
Nicholas Shanks

Reputation: 10991

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

Upvotes: 5

Vivin Paliath
Vivin Paliath

Reputation: 95588

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

Upvotes: 19

Lan
Lan

Reputation: 6640

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.

Upvotes: 10

Related Questions