Rate Limiting और Quotas

सीमाएँ एक feature हैं

सीमाओं के बिना एक ग़लत loop या दुरुपयोगी client सबके लिए सेवा गिरा सकता है। प्रति API key, user या IP rate limits लगाएँ (जैसे प्रति मिनट 100 अनुरोध) और कभी-कभी quotas (प्रति दिन या महीना), अक्सर token-bucket या sliding-window algorithm से। Clients को बताएँ कि वे कहाँ हैं: आम headers हैं RateLimit-Limit, RateLimit-Remaining और RateLimit-Reset (IETF draft मानक, जबकि कई सेवाएँ अब भी X-RateLimit-* नाम उपयोग करती हैं), और रोके जाने पर Retry-After (सेकंड या तारीख़) के साथ 429 Too Many Requests लौटाएँ। सुव्यवहारी clients तब पीछे हटते हैं। महँगे endpoints (search, exports) और login प्रयासों पर कड़ी सीमाएँ ठीक हैं।

सीमा छूना, चलाकर

मैंने यह केवल Python standard library से बने छोटे असली HTTP API पर चलाया (पूरा कोड केस स्टडी में)। /limited route 3 अनुरोधों की अनुमति देता है। Headers बचे अनुरोध घटते दिखाते हैं (2, 1, 0), फिर चौथी और पाँचवीं call Retry-After: 30 के साथ 429 पाती हैं। (Output स्तंभ: status, remaining, retry-after।)

# uses srv, base and call() from the runnable demo in the case study
for _ in range(5):
    s, h, b = call("GET", "/limited"); print(s, h.get("X-RateLimit-Remaining"), h.get("Retry-After"))
srv.shutdown()

Output:

200 2 None
200 1 None
200 0 None
429 0 30
429 0 30

Client-side backoff, चलाकर

मैंने यह सादा-Python उदाहरण चलाया। Client को Retry-After हो तो उसका पालन करना चाहिए, वरना एक सीमा तक घातीय रूप से पीछे हटना चाहिए: 1, 2, 4, 8, 16, फिर 30 सेकंड। Retry-After: 30 के साथ वह ठीक 30 इंतज़ार करता है।

import hmac, hashlib, json, time, bisect

def next_delay(attempt, retry_after=None, base=1.0, cap=30.0):
    return float(retry_after) if retry_after is not None else min(cap, base * 2 ** attempt)
print([next_delay(a) for a in range(6)], next_delay(2, "30"))

Output:

[1.0, 2.0, 4.0, 8.0, 16.0, 30.0] 30.0

त्वरित जाँच: कौन-सा status और header client को इंतज़ार करने को कहते हैं?

• 301 और Location
• 200 और Content-Length
• 404 और ETag
• 429 और Retry-After