I like their 429 guidance: https://opensource.zalando.com/restful-api-guidelines/#153 https://opensource.zalando.com/restful-api-guidelines/#153 This has massi

I like their 429 guidance: https://opensource.zalando.com/restful-api-guidelines/#153 https://opensource.zalando.com/restful-api-guidelines/#153 This has massive implications in real-world systems. Rate limiting adds and order of magnitude complexity to a client system due to the next for delayed, conditional execution. So many APIs do rate limiting and don't bother to add information about why it is happening or for how long the limit applies. I've been working with a name-brand system that limits based both on client application and end user. So, effectively, there can be a 429 because the application as a whole is exhausted, or because a particular user is exhausted. There is no additional information, so the only way to know if the limit has lapsed is to try again. It make it incredibly cumbersome to create reliable consumer applications.