Should I Use PUT Instead of DELETE When I Have to Send a Payload to the HTTP Request?

Question

The application that I am creating has a DELETE API which basically sets the Active column of a database record to 0. I pass the Id via the query parameters to identify which record needs to be deactivated.

However, recently I received an additional request from my project manager wherein I should store the user ID and the application ID that initiated the deletion.

With this, should I just pass these two additional information via the query parameter or would it make more sense to change the API to accept PUT requests instead?

Answer 1

Since userID and applicationID in this scenario seem to be metadata (not data strictly related to the resource deletion) you could also pass that information in the HTTP headers.

DELETE /resource/{resourceId}
X-UserId: userId
X-AppId: appId

{empty body}

Answer 2

PUT is meant to be idempotent. That is, if I do the same action 100 times (say, a Monkey jumps on the enter key), it should only change the state of the item 1 time, the first time, the rest of the operations should effectively be No-Ops.

How a PUT accomplishes this semantically is by including all of the state in the request itself, effectively replacing the resource's representation on the server.

My real question would be, why do you care whether it's a PUT or a DELETE? Semantically if your request satisifies what a PUT wants, it could be a PUT; and there's no prohibition against having a request body with a DELETE request.

If it were me, unless I wanted to maintain strong REST semantics for other purposes, I'd likely just use a POST request, since a POST indicates this action has side effects to future callers, and I don't see a reason to specialize the request as in this case it doesn't seem to buy anything.

Answer 3

Patch is ideal for this request, since you want to partially update your resource. learn more about patch here