4 ms·

Why give out an error at all? The intention of the API call is fulfilled either way. The spec regarding this: "A successful response SHOULD be 200 (OK) if the

by mAritz 13y ago

Why give out an error at all? The intention of the API call is fulfilled either way. The spec regarding this: "A successful response SHOULD be 200 (OK) if the response includes an entity describing the status, 202 (Accepted) if the action has not yet been enacted, or 204 (No Content) if the action has been enacted but the response does not include an entity." 204 is what I would return for most DELETEs because there is no status (entity) left after a normal delete.

drone 13y ago
The problem I find with this solution is that it makes it difficult to tell if the client is operating properly. That is, I can't tell if my client is spuriously trying to delete the same resources from the status codes if there is no difference between a status code for successful deletion, and an attempt to delete an object that does not exist. As an API consumer, I would prefer a 404 not found - so that I may easily and accurately populate up the information that a resource I expected to be there, and to delete, wasn't there when I tried to delete it. Especially in complex applications where various clients may be running against the same data set across many distributed nodes, this can be demonstrative of many much harder-to-find problems when every action is "success." I also would prefer 200 - with a description of the entity that was deleted, again, for verification and system maintenance needs.
- dragonwriter 13y ago
  > That is, I can't tell if my client is spuriously trying to delete the same resources from the status codes if there is no difference between a status code for successful deletion, and an attempt to delete an object that does not exist. Presumably, if you are logging status codes received by your client, you are also logging the requests that produce them; you should be able to determine if it is spuriously trying to delete the same resources from the request history. The only status code you need to make this determination is the 2xx received from the first successful request.
  - drone 13y ago
    Experience has taught me that it is far easier to catch negative anomalies (an apparently bad thing happened), than it is to catch positive anomalies (things that look normal, but are actually bad). Consider that to catch two nodes deleting the same resource, you'd need to correlate the messages from all nodes. (Or, at least, know that there may be a problem with nodes trying to delete the same resource, and plan by recording every resource deleted in some other node.) Whereas, with a 404, you can determine that there is a problem in one message - and have the resource information to search through your history and find related events. Given that some of the systems I've worked in have had thousands of nodes - I'd rather not go through the log history from each node on every normal event to verify that it isn't actually abnormal. At a certain scale, relying on correlation and positive anomaly detection approaches such a level of difficulty as to be nearly impossible.
    - dragonwriter 13y ago
      > Consider that to catch two nodes deleting the same resource, you'd need to correlate the messages from all nodes. Generally, two nodes trying to delete the same resource isn't an anomaly. (The result of those attempts being something other than the resource being deleted exactly as if one attempt was made to deleted would be an anomaly, as it would the same node attmepting to delete the node more than once after having received confirmation that it had been deleted on an earlier effort.)
papsosouid 13y ago
>Why give out an error at all? Because that is useful information. What benefit is there to hiding the information?
- strickjb9 13y ago
  I draw the line on what a real error - 4xx doesn't seem to fit the bill. If you want information then a 2xx code and/or a JSON body would be ideal (for me). I think this is the crux of the debate is where do you draw the line?
  - papsosouid 13y ago
    That doesn't make any sense. The line was already drawn, in the HTTP spec. Follow it. Returning 200 OK for everything and then putting an error in the the body is completely useless. The whole point is that there are common, well defined errors which HTTP specifies codes for. Clients can properly handle those errors regardless of what the backend is like. Nobody wants to have to write millions of different solutions to parse your JSON error responses and figure out what they mean and what to do with them.

by mAritz 13y ago

drone 13y ago

The problem I find with this solution is that it makes it difficult to tell if the client is operating properly. That is, I can't tell if my client is spuriously trying to delete the same resources from the status codes if there is no difference between a status code for successful deletion, and an attempt to delete an object that does not exist. As an API consumer, I would prefer a 404 not found - so that I may easily and accurately populate up the information that a resource I expected to be there, and to delete, wasn't there when I tried to delete it. Especially in complex applications where various clients may be running against the same data set across many distributed nodes, this can be demonstrative of many much harder-to-find problems when every action is "success." I also would prefer 200 - with a description of the entity that was deleted, again, for verification and system maintenance needs.

dragonwriter 13y ago
> That is, I can't tell if my client is spuriously trying to delete the same resources from the status codes if there is no difference between a status code for successful deletion, and an attempt to delete an object that does not exist. Presumably, if you are logging status codes received by your client, you are also logging the requests that produce them; you should be able to determine if it is spuriously trying to delete the same resources from the request history. The only status code you need to make this determination is the 2xx received from the first successful request.
- drone 13y ago
  Experience has taught me that it is far easier to catch negative anomalies (an apparently bad thing happened), than it is to catch positive anomalies (things that look normal, but are actually bad). Consider that to catch two nodes deleting the same resource, you'd need to correlate the messages from all nodes. (Or, at least, know that there may be a problem with nodes trying to delete the same resource, and plan by recording every resource deleted in some other node.) Whereas, with a 404, you can determine that there is a problem in one message - and have the resource information to search through your history and find related events. Given that some of the systems I've worked in have had thousands of nodes - I'd rather not go through the log history from each node on every normal event to verify that it isn't actually abnormal. At a certain scale, relying on correlation and positive anomaly detection approaches such a level of difficulty as to be nearly impossible.
  - dragonwriter 13y ago
    > Consider that to catch two nodes deleting the same resource, you'd need to correlate the messages from all nodes. Generally, two nodes trying to delete the same resource isn't an anomaly. (The result of those attempts being something other than the resource being deleted exactly as if one attempt was made to deleted would be an anomaly, as it would the same node attmepting to delete the node more than once after having received confirmation that it had been deleted on an earlier effort.)

papsosouid 13y ago

>Why give out an error at all? Because that is useful information. What benefit is there to hiding the information?

strickjb9 13y ago
I draw the line on what a real error - 4xx doesn't seem to fit the bill. If you want information then a 2xx code and/or a JSON body would be ideal (for me). I think this is the crux of the debate is where do you draw the line?
- papsosouid 13y ago
  That doesn't make any sense. The line was already drawn, in the HTTP spec. Follow it. Returning 200 OK for everything and then putting an error in the the body is completely useless. The whole point is that there are common, well defined errors which HTTP specifies codes for. Clients can properly handle those errors regardless of what the backend is like. Nobody wants to have to write millions of different solutions to parse your JSON error responses and figure out what they mean and what to do with them.