3 ms·

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 th

by 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.
- papaf 6y ago
  I can’t imagine any way a reverse proxy would generate a 404 or indeed any 4xx error within itself. What if the configuration changes and the API path/URL is no longer in the reverse proxy config? What if the reverse proxy is dynamically configured and our application didn't register itself properly? They _do_ understand http status codes and can act accordingly, like retrying requests, not caching responses, etc as appropriate. Of course applications should return HTTP codes when appropriate e.g 500. The principle is that using HTTP codes for application specific information e.g item not found in DB, is a blunt instrument. They have no way to unpack and interpret every developers pet error format. I would argue that they don't need to. The conversation is between client and API at higher level than HTTP. HTTP codes are great for information such as "its broken", "please authenticate", "its busy". But HTTP codes are not so useful for things such as "item not in db", "parameter x is missing", "unsupported API version" because this information is nothing to do with HTTP.
InvOfSmallC 6y ago
404 is a normal response code. Something is wrong in the infrastructure if you have this doubts.

by papaf 6y ago

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.

papaf 6y ago
I can’t imagine any way a reverse proxy would generate a 404 or indeed any 4xx error within itself. What if the configuration changes and the API path/URL is no longer in the reverse proxy config? What if the reverse proxy is dynamically configured and our application didn't register itself properly? They _do_ understand http status codes and can act accordingly, like retrying requests, not caching responses, etc as appropriate. Of course applications should return HTTP codes when appropriate e.g 500. The principle is that using HTTP codes for application specific information e.g item not found in DB, is a blunt instrument. They have no way to unpack and interpret every developers pet error format. I would argue that they don't need to. The conversation is between client and API at higher level than HTTP. HTTP codes are great for information such as "its broken", "please authenticate", "its busy". But HTTP codes are not so useful for things such as "item not in db", "parameter x is missing", "unsupported API version" because this information is nothing to do with HTTP.

InvOfSmallC 6y ago

404 is a normal response code. Something is wrong in the infrastructure if you have this doubts.