CODEWITHSUNDEEP
resthttp
mark vanzuela
mark vanzuela

Reputation: 1391

Correct HTTP Status Code for requests that has something wrong with the process but not an exception

The scenario is the client will request to delete an item in the table but the item is deleted already, not physically deleted so not a "NOT FOUND". Probably a 200 but it has not done the delete. Something like in between the 200 and a 500.

A return for a request for something to be done but it was not done successfully(so not a 200) but there is no exception(not a 500).

Upvotes: 0

Views: 295

Answers (2)

VoiceOfUnreason
VoiceOfUnreason

Reputation: 57259

Status codes belong to the transfer documents over a network domain; you want to be thinking of them in terms of general purpose document transfer semantics, not anything specific to your implementation.

One of the interesting characteristics of unsafe idempotent methods is that they are, in a sense, declarative -- "make the resource be like this". If the resource is already in the desired state, you can return a success response to indicate that.

This is made explicit in RFC 7232, discussing the implications of If-Match headers:

An origin server MUST NOT perform the requested method if a received If-Match condition evaluates to false; instead, the origin server MUST respond with either a) the 412 (Precondition Failed) status code or b) one of the 2xx (Successful) status codes if the origin server has verified that a state change is being requested and the final state is already reflected in the current state of the target resource (i.e., the change requested by the user agent has already succeeded, but the user agent might not be aware of it, perhaps because the prior response was lost or a compatible change was made by some other user agent).

Fundamentally, HTTP doesn't constrain what servers do (implementation), but only what the messages mean (semantics). In the case of a No-Op, returning a message with a success code has perfectly satisfactory meaning, and in particular induces (in a standards compliant client) exactly the sorts of responses that we want.

Success codes can also be appropriate when an unsafe request changes a resource, but not in the expected way. Again, the server has authority over its own implementation, what we're largely interested in is what information is communicated to the client.

As an example, I submit a reimbursement request. What I expect is that my request goes to the "approved" state, but it might instead transition to "under review" if some business rule has kicked in. I still expect to receive a 2xx status code back, even though the server didn't do "what I wanted", because the message has been received and acted upon, and my previously cached copy of the resource involved is no longer valid.

Upvotes: 1

Evert
Evert

Reputation: 99533

If you are doing a request on a resource that doesn't exist, you can still just use 404 Not Found. Whether something is 'physically deleted' or not is irrelevant to the client.

If you know for a fact that it's deleted before and it's never coming back, 410 Gone is also appropriate

Upvotes: 1

Related Questions