Re: [httpapi] RateLimit Header client implementations

[Darrel Miller <[e-mail]>]

Alex,

Thanks for the additional context.
You are right, the immediate effect is the same. That said, you would be lacking some extra information about the nominal quota units and duration of the current window and the windows applying after this one is elapsed (ie. after recovery you'd have information about the expected rates, and those could also signal some sort of punitive policy), though that information might be next to useless in the current window since the intended effect is to stop traffic altogether for a while. Yet it would not work in a closely related scenario in which you would have some partial maintenance work but keeping the ability to serve clients in a degraded service manner -- that is, unless you kept giving clients shorter no-service windows interleaved with service responses as usual, hence generating a lot more wasteful traffic.
Would be useful to clarify that these additional headers are intended to support scenarios where rate limiting constraints applied by a service are dynamic over time?
 Yes, I believe that because there is no standardization there's been little to no effort in writing such adaptive code in generic HTTP clients, but this is pure speculation. I think it is very likely that most people doing so are the ones writing service specific clients, and in many cases they could be the same people that wrote the service in the first place, unless the service happens to see lots of usage across the board with many independent clients.
I look forward to seeing some feedback from implementers on the value derived from generic client code that handles these headers.

Darrel