429 Too Many Requests ?

[codyaray]

I don't see this in the decision diagram. Not sure if it was just an oversight, but it's super common for rate limiting nowadays.

Same with 402 Payment Required. This is less common than 429s but is becoming more popular for quota/plan enforcement:

• google
• asana
• shopify
• clearbit

https://www.codetinkerer.com/2015/12/04/choosing-an-http-status-code.html

[andreineculau]

Thanks for your question. The decision diagram is not extensive, so from that perspective it can be "improved". That said, there are many other status codes in the world and the purpose is not too have them all crammed in here.

When it comes specifically to the two codes you mentioned, it is not possible to say when you should check for the system/call state that would trigger those responses.

For instance you could throw Too Many Requests already in the system block, but at times it depends you need to actually prices the requests e.g. "ohh you are trying to update this field in the resource too often".

But like i said, the diagram is not extensive not comprehensive. It covers many common scenarios in a logical way. That doesn't stop anyone from throwing 429 in the system/request's is_block_ok? decision

Let me know if something is unclear. And good luck!

-- http://andreineculau.com

On 25 Apr 2020, at 09:00, Cody A. Ray [email protected] wrote:

 I don't see this in the decision diagram. Not sure if it was just an oversight, but it's super common for rate limiting nowadays.

Same with 402 Payment Required. This is less common than 429s but is becoming more popular for quota/plan enforcement:

google asana shopify clearbit https://www.codetinkerer.com/2015/12/04/choosing-an-http-status-code.html

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or unsubscribe.