4 ms·

I've seen this pattern before, and one can argue that it is the correct one. Your options are your http status are your application's status, which I think is w

by dastx 6y ago

I've seen this pattern before, and one can argue that it is the correct one. Your options are your http status are your application's status, which I think is what most of us are used to. The other one is http status codes are http status codes. As in the http request was done correctly, but the application code wasn't. More specifically, http layer was executed successfully, but the application layer was not.

mindwok 6y ago
But there's response codes for those situations. If the request is malformed you should send a 400 bad request. If the application errored, send something in the 500 range.
spicyramen 6y ago
I just had an issue today in which customer deleted a service account (which they shouldn't touch) required by our API to process their entities. Right now I send a 5xx server error but as is a customer misconfiguration problem, and problem is not on the server side and is not a bad request, but a setting client changed I would use this pattern. This will avoid triggering our alerts.
daxfohl 6y ago
This is more RPC style. I used to prefer this approach because that way you're not constrained to the Nxx error codes of http; it's just request, response. Having worked in a few companies since then, it seems odd to me now. Besides, all your middleware etc is probably going to use status codes conventionally, so your application code's 2xx error responses will stick out like a sore thumb.
lenkite 6y ago
That is simply a 500 error. Or a 422 if request was semantically wrong. No, this pattern is not the right one for REST. Don't call it REST, call it command/action RPC. The 90s called - they want their architecture back.
papaf 6y ago
Your options are your http status are your application's status, which I think is what most of us are used to. I used to use HTTP status codes in this way because I understood it was the correct REST way of doing things. However, one day, a sysadmin contacted me to tell me that we had broken a release because our API was returning a 404. Actually it was a problem in the checking script that was checking for data that was no longer in the DB. By making application codes equal to HTTP status codes, we had removed any way to distinguish between fatal errors and API results.
- stouset 6y ago
  404 is literally the correct response for this behavior, per the HTTP spec. There was no server-side error. The requested resource was unable to be located because it no longer existed. You should return a 404 here, and not just for non-HTML API clients. Application-side fatal errors are in the 500 block. So yes, you absolutely can distinguish this case.
  - papaf 6y ago
    The requested resource was unable to be located because it no longer existed. I should have mentioned that the API was behind a reverse proxy. This leads to the following questions: Which requested resource is missing? The API itself or the item requested from the API? How does a client distinguish between these?
    - davidbanham 6y ago
      I can’t imagine any way a reverse proxy would generate a 404 or indeed any 4xx error within itself. Any such error would be coming from the upstream application server. If the API itself was not found that’s one of 502, 503 or 504. 200 responses with an error property is an antipattern precisely because of things like reverse proxies. They have no way to unpack and interpret every developers pet error format. They _do_ understand http status codes and can act accordingly, like retrying requests, not caching responses, etc as appropriate.
goatinaboat 6y ago
I've seen this pattern before, and one can argue that it is the correct one. Your options are your http status are your application's status, which I think is what most of us are used to. It's pretty infuriating actually. On a similar note I have to use certain command line tools provided by a third party vendor that exits 0 on failure, and writes something to STDERR (on success it exits 0 and writes something to STDOUT). The Unix conventions evolved over decades because they were consistent and useful.
initplus 6y ago
A downside of "200 for everything, error in the body" is that it locks you out from using off the shelf API monitoring tools. Now you need some custom monitoring tool that can read & understand your custom error bodies.
halayli 6y ago
You're on the Internet. You are going to see all patterns and combinations you can think about. But there's an rfc and that's what defines correct usage.

by dastx 6y ago

mindwok 6y ago

But there's response codes for those situations. If the request is malformed you should send a 400 bad request. If the application errored, send something in the 500 range.

spicyramen 6y ago

I just had an issue today in which customer deleted a service account (which they shouldn't touch) required by our API to process their entities. Right now I send a 5xx server error but as is a customer misconfiguration problem, and problem is not on the server side and is not a bad request, but a setting client changed I would use this pattern. This will avoid triggering our alerts.

daxfohl 6y ago

This is more RPC style. I used to prefer this approach because that way you're not constrained to the Nxx error codes of http; it's just request, response. Having worked in a few companies since then, it seems odd to me now. Besides, all your middleware etc is probably going to use status codes conventionally, so your application code's 2xx error responses will stick out like a sore thumb.

lenkite 6y ago

That is simply a 500 error. Or a 422 if request was semantically wrong. No, this pattern is not the right one for REST. Don't call it REST, call it command/action RPC. The 90s called - they want their architecture back.

papaf 6y ago

Your options are your http status are your application's status, which I think is what most of us are used to. I used to use HTTP status codes in this way because I understood it was the correct REST way of doing things. However, one day, a sysadmin contacted me to tell me that we had broken a release because our API was returning a 404. Actually it was a problem in the checking script that was checking for data that was no longer in the DB. By making application codes equal to HTTP status codes, we had removed any way to distinguish between fatal errors and API results.

stouset 6y ago
404 is literally the correct response for this behavior, per the HTTP spec. There was no server-side error. The requested resource was unable to be located because it no longer existed. You should return a 404 here, and not just for non-HTML API clients. Application-side fatal errors are in the 500 block. So yes, you absolutely can distinguish this case.
- papaf 6y ago
  The requested resource was unable to be located because it no longer existed. I should have mentioned that the API was behind a reverse proxy. This leads to the following questions: Which requested resource is missing? The API itself or the item requested from the API? How does a client distinguish between these?
  - davidbanham 6y ago
    I can’t imagine any way a reverse proxy would generate a 404 or indeed any 4xx error within itself. Any such error would be coming from the upstream application server. If the API itself was not found that’s one of 502, 503 or 504. 200 responses with an error property is an antipattern precisely because of things like reverse proxies. They have no way to unpack and interpret every developers pet error format. They _do_ understand http status codes and can act accordingly, like retrying requests, not caching responses, etc as appropriate.

goatinaboat 6y ago

I've seen this pattern before, and one can argue that it is the correct one. Your options are your http status are your application's status, which I think is what most of us are used to. It's pretty infuriating actually. On a similar note I have to use certain command line tools provided by a third party vendor that exits 0 on failure, and writes something to STDERR (on success it exits 0 and writes something to STDOUT). The Unix conventions evolved over decades because they were consistent and useful.

initplus 6y ago

A downside of "200 for everything, error in the body" is that it locks you out from using off the shelf API monitoring tools. Now you need some custom monitoring tool that can read & understand your custom error bodies.

halayli 6y ago

You're on the Internet. You are going to see all patterns and combinations you can think about. But there's an rfc and that's what defines correct usage.