Update ratelimit headers #29
Conversation
change headers to whats used already
|
Won't it break anything that already uses these headers though? 🤔 Also if we're making a backwards-incompatible change, we should probably drop the
|
|
It was copied from Twitter IIRC, which does use I don't really care btw; don't really see the point in changing, but if you change it you should also update the API spec. I also don't know if we document this in any user-facing documentation (we might in Desk for example), so you would need to check that, too (but again, doesn't really seem worth it, IMHO). |
|
Yes it might break things for people who use theese headers atm but thats a lot less than people using the old headers. I've seen that rfc thing but its still commonly used across the board. @Carpetsmoker the point is to be consistent with what we did before as theres, as you also say, no need to change theese headers. A lot more customers are used to the old x-ratelimit-header. Someone needs to update his stuff for sure its just a matter of how many people. Projects is overwriting those headers atm which shouldn't be needed ultimately if we have the same header everywhere. |
|
These were always the headers that were used in e.g. Desk, Launchpad, etc, so from that perspective there are no "new" and "old" headers. |
|
Yea just leave it open for now. |
|
To be clear, I'm not saying you can't change it, just that you need to be careful to change it everywhere, including the docs etc. |
|
yep absolutely right. |
Changing the ratelimit headers to what we've been using already to make it consistent with old and new api. No need to change what is well known and working.
x-rateLimit is a common term used by many publishers.
see https://developer.github.com/v3/rate_limit/ as an example
splitting the term ratelimit in two parts is just unnecessary.