5 ms·

That last suggestion (of returning 200 but with a message explaining that usage limit has been reached) seems odd to me - I'm not saying I haven't seen code tha

That last suggestion (of returning 200 but with a message explaining that usage limit has been reached) seems odd to me - I'm not saying I haven't seen code that simply retries on any error but that could just as well include an error trying to parse the response and extract meaningful values from it. What I have observed is that client code often logs or relays HTTP status response codes (and 429 explicitly exists for this case) but rarely bothers doing the same for unexpected message content, which at best might be logged or conveyed to an end user as some sort of "failed to parse" exception. Surely a better option to avoid getting hammered is to return 429 after a 15-20 second delay?

whartung 3y ago
I think the premise here is that a 4xx is an “expected” server issue, which the code may be able to handle (i.e. retry) whereas a 200 followed by a parse error is an “application problem” that they’re not prepared to handle. A 200 may mean the payload has changed, and how would an app handle an arbitrary format change? This could well fall into the “don’t test for something you can’t handle”. At a minimum it’ll ideally get the app to quiet down.
- capableweb 3y ago
  > I think the premise here is that a 4xx is an “expected” server issue That premise is incorrect, as 4xx is client errors, as in the client formatted the request wrong or anything else, and therefore it couldn't be responded to. Rate-limiting is the client hitting the server too much, and it's up the client to handle this. 5xx is for server issues. 2xx should be success in any shape or form, so clearly 2xx shouldn't be used in this case either. I agree that 429 should just be used for it's intended purpose here, handling rate-limiting requests/responses. You can still add a body if you want, with the current quotas.
  - bbkane 3y ago
    From my reading, this "hand out a 2xx and an error message" advice is for badly behaved clients who are retrying when they get 4xx. It's not what "should" be used, it's what the author found to be effective.
    - laserbeam 3y ago
      Which is slightly strange because it contradicts the previous suggestion: don't be too liberal of what you accept.
    - 21eleven 3y ago
      I like the detail from the top comment of replying w a 429 after a many second delay. That would mitigate any retry storm.
    - capableweb 3y ago
      > From my reading, this "hand out a 2xx and an error message" advice is for badly behaved clients who are retrying when they get 4xx. But trying to handle clients who mishandle things like that is a fools errand. What client, in their right mind, would try to retry a request that is failing because of what the client is sending? In no case does that make sense, ever. Similarly, should everything just be 200 then just in case clients mishandle redirect requests?
      - sfn42 3y ago
        A lot of developers are idiots. There is tons of code out there doing exactly this kind of thing. People will copy random snippets from SO and smack them with a hammer until they seem to work then move on to the next thing. I've seen some incredibly stupid code out there, code I can only assume the author either didn't understand or truly didn't give a fuck about. Probably both.
        capableweb 3y ago
        > A lot of developers are idiots. There is tons of code out there doing exactly this kind of thing. Sure, I agree a lot with this, but that doesn't mean you and me should also do idiotic things. Lets just return correct status codes and the ones who misuse it, will misuse it :)
  - wizofaus 3y ago
    To be fair in some cases rate-limiting could be triggered by a server-side issue, technically there's a 529 error for that, but I can't recall seeing it used. But 4xx errors should exist as an indication to clients that there's no point immediately retrying the same request. If they're not honouring that, delaying before responding seems the most reasonable course of action.
- wizofaus 3y ago
  I'm even guilty of writing client code that just retries on failing to parse the response, precisely because the server I was working with randomly would return empty/corrupt responses for no discernible reason (it was actually Amex's API sandbox). Come to think of it, perhaps it was trying to rate limit us, as it happened a lot running our integration test suites! But the fact it returned 200 and even text/html as the content type was a bit ridiculous.
laserbeam 3y ago
I fully agree. Any error should not return a 2xx code. All clients should be safe to assume that 2xx is cool and they can just move forward and use the output. If suddenly 2% of your 2xx responses are errors it becomes fun time to sort out where data got corrupted a few months after you started to use an API. Handling errors as a client also becomes nasty.

whartung 3y ago

I think the premise here is that a 4xx is an “expected” server issue, which the code may be able to handle (i.e. retry) whereas a 200 followed by a parse error is an “application problem” that they’re not prepared to handle. A 200 may mean the payload has changed, and how would an app handle an arbitrary format change? This could well fall into the “don’t test for something you can’t handle”. At a minimum it’ll ideally get the app to quiet down.

capableweb 3y ago
> I think the premise here is that a 4xx is an “expected” server issue That premise is incorrect, as 4xx is client errors, as in the client formatted the request wrong or anything else, and therefore it couldn't be responded to. Rate-limiting is the client hitting the server too much, and it's up the client to handle this. 5xx is for server issues. 2xx should be success in any shape or form, so clearly 2xx shouldn't be used in this case either. I agree that 429 should just be used for it's intended purpose here, handling rate-limiting requests/responses. You can still add a body if you want, with the current quotas.
- bbkane 3y ago
  From my reading, this "hand out a 2xx and an error message" advice is for badly behaved clients who are retrying when they get 4xx. It's not what "should" be used, it's what the author found to be effective.
  - laserbeam 3y ago
    Which is slightly strange because it contradicts the previous suggestion: don't be too liberal of what you accept.
  - 21eleven 3y ago
    I like the detail from the top comment of replying w a 429 after a many second delay. That would mitigate any retry storm.
  - capableweb 3y ago
    > From my reading, this "hand out a 2xx and an error message" advice is for badly behaved clients who are retrying when they get 4xx. But trying to handle clients who mishandle things like that is a fools errand. What client, in their right mind, would try to retry a request that is failing because of what the client is sending? In no case does that make sense, ever. Similarly, should everything just be 200 then just in case clients mishandle redirect requests?
    - sfn42 3y ago
      A lot of developers are idiots. There is tons of code out there doing exactly this kind of thing. People will copy random snippets from SO and smack them with a hammer until they seem to work then move on to the next thing. I've seen some incredibly stupid code out there, code I can only assume the author either didn't understand or truly didn't give a fuck about. Probably both.
      - capableweb 3y ago
        > A lot of developers are idiots. There is tons of code out there doing exactly this kind of thing. Sure, I agree a lot with this, but that doesn't mean you and me should also do idiotic things. Lets just return correct status codes and the ones who misuse it, will misuse it :)
- wizofaus 3y ago
  To be fair in some cases rate-limiting could be triggered by a server-side issue, technically there's a 529 error for that, but I can't recall seeing it used. But 4xx errors should exist as an indication to clients that there's no point immediately retrying the same request. If they're not honouring that, delaying before responding seems the most reasonable course of action.
wizofaus 3y ago
I'm even guilty of writing client code that just retries on failing to parse the response, precisely because the server I was working with randomly would return empty/corrupt responses for no discernible reason (it was actually Amex's API sandbox). Come to think of it, perhaps it was trying to rate limit us, as it happened a lot running our integration test suites! But the fact it returned 200 and even text/html as the content type was a bit ridiculous.

laserbeam 3y ago

I fully agree. Any error should not return a 2xx code. All clients should be safe to assume that 2xx is cool and they can just move forward and use the output. If suddenly 2% of your 2xx responses are errors it becomes fun time to sort out where data got corrupted a few months after you started to use an API. Handling errors as a client also becomes nasty.