'अनुरोध सीमा तक पहुँच' के लिए सुझाया गया HTTP REST स्थिति कोड

Question

मैं एक REST सेवा के लिए एक युक्ति लगा रहा हूं, जिसका एक हिस्सा उपयोगकर्ताओं को सेवा-व्यापी और व्यक्तिगत या संसाधनों के समूहों पर थ्रॉटल करने की क्षमता को शामिल करेगा। समान रूप से, इन के लिए समय-आउट प्रति संसाधन / समूह / सेवा के लिए विन्यास योग्य होगा।

मैं बस HTTP 1.1 युक्ति को देख रहा हूं और यह तय करने की कोशिश कर रहा हूं कि मैं एक ग्राहक से कैसे संवाद करूंगा कि एक अनुरोध पूरा नहीं होगा क्योंकि वे अपनी सीमा तक पहुंच चुके हैं।

शुरू में मुझे लगा कि ग्राहक कोड 403 - Forbiddenएक था, लेकिन यह कल्पना से:

प्राधिकरण मदद नहीं करेगा और अनुरोध को दोहराया नहीं जाना चाहिए

मुझे परेशान किया।

यह वास्तव में प्रतीत होता है कि 503 - Service Unavailableउपयोग करने के लिए एक बेहतर है - क्योंकि यह Retry-Afterहेडर के उपयोग के माध्यम से एक रिट्री टाइम के संचार के लिए अनुमति देता है ।

यह संभव है कि भविष्य में मैं ई-कॉमर्स के माध्यम से 'अधिक खरीद' का समर्थन करने के लिए देख सकता हूं (अगर ग्राहक कोड 402 - Payment Requiredको अंतिम रूप दिया गया था तो यह अच्छा होगा !) - लेकिन मुझे लगता है कि यह समान रूप से 503 प्रतिक्रिया में भी निचोड़ा जा सकता है।

जो आपको लगता है कि मुझे उपयोग करना चाहिए? या वहाँ एक और मैं नहीं माना जाता है?

Answer 1

429 बहुत सारे अनुरोध

उपयोगकर्ता ने दिए गए समय में बहुत सारे अनुरोध भेजे हैं। दरों को सीमित करने वाली योजनाओं के उपयोग के लिए इरादा। यह कोड RFC 6585 अतिरिक्त HTTP स्थिति कोड में स्वीकार किया गया है ।

   The 429 status code indicates that the user has sent too many
   requests in a given amount of time ("rate limiting").

   The response representations SHOULD include details explaining the
   condition, and MAY include a Retry-After header indicating how long
   to wait before making a new request...

   Note that this specification does not define how the origin server
   identifies the user, nor how it counts requests.  For example, an
   origin server that is limiting request rates can do so based upon
   counts of requests on a per-resource basis, across the entire server,
   or even among a set of servers.  Likewise, it might identify the user
   by its authentication credentials, or a stateful cookie.

   Responses with the 429 status code MUST NOT be stored by a cache...

Comments

भयानक लगता है - मैं इसे ध्यान में रखूँगा! क्या यह मुफ्त बिल्लियों के साथ आता है? या वे प्रोटोकॉल के लिए एक विस्तार कर रहे हैं?

— एंड्रास ज़ोल्टन

HTTP स्थिति बिल्लियाँ - आपकी सभी आवश्यकताओं के लिए: flickr.com/photos/girliemac/sets/72157628409467125

— सीन मैकमिलन

बस बहुत हँसी और तालियों के साथ कार्यालय का चक्कर लगाया है - प्रतिभा!

— आंद्रा ज़ोल्टन

मैं अंत में एक 429 के साथ चला गया - यह मसौदा कल्पना में है, लेकिन मुझे गंभीरता से संदेह है कि यह अंत में किसी और चीज के लिए इस्तेमाल किया जाएगा।

— एंड्रास ज़ोल्टन

Answer 2

एक हद तक, आप उन चीज़ों को करने के लिए स्वतंत्र हैं, जो आपको कोड के साथ पसंद हैं, लेकिन मैं सहमत हूं कि आप उपयोग कर सकते हैं 503, या यदि आप चाहते हैं 402, तो बिना किसी को शिकायत किए कि आप चीजों को तोड़ रहे हैं।

संपादित करें: एक शुद्धतावादी कह सकता है कि आपको 503 से शुरू करना चाहिए, फिर भुगतान करने के लिए एक बार स्विच करें।

---

इस टिप्पणी में एक उत्कृष्ट इसके अलावा:

4xx क्लाइंट द्वारा एक त्रुटि को इंगित करता है जिसे उनके द्वारा एक निश्चित कार्रवाई करने के द्वारा तय किया जा सकता है, जबकि 5xx सर्वर पर एक समस्या को इंगित करता है जो क्लाइंट को हल करने में मदद नहीं कर सकता है। तो आपके मामले में, एक 4xx अधिक उपयुक्त है, क्योंकि (i) सर्वर बिल्कुल वैसा ही व्यवहार कर रहा है जैसा कि करना चाहिए, और (ii) क्लाइंट या तो क्रेडिट को धीमा कर सकता है या अधिक क्रेडिट खरीद कर "ठीक" कर सकता है। 429 प्रतिक्रिया के शरीर में सटीक रिज़ॉल्यूशन का संकेत दिया जा सकता है। - माइक चेम्बरलेन 7 घंटे पहले

Comments

503! 503! 503! सीमा पर पहुंच गया, अगली कॉल निषिद्ध है। सादा और सरल ...

— यनीस

@YannisRizos: आह, लेकिन भुगतान किए जाने के बाद यह मना नहीं है!

— मार्सिन

त्रुटि कोड एकल अनुरोध के परिणाम का प्रतिनिधित्व करता है। यदि भुगतान किया गया था, तो बाद के अनुरोध पर यह हमेशा की तरह व्यवसाय है ... यदि आप व्यवहार का दस्तावेजीकरण करते हैं, तो यह मेरे द्वारा ठीक है। या आप एक त्रुटि संदेश के साथ सिर्फ 200 वापस कर सकते हैं। लेकिन यह सुंदर नहीं है। हालाँकि कुछ लोग कह सकते हैं कि व्यापार तर्क के लिए HTTP त्रुटि कोड का उपयोग करना बहुत अच्छा नहीं है। आह ठीक है, मैं व्यक्तिगत रूप से 503 के साथ जाऊंगा, इस समय सेवा उपलब्ध नहीं है - जब तक कि 402 आमतौर पर समर्थित नहीं है।

— यानिस

@YannisRizos (& Marcin) - आपकी टिप्पणियों के लिए धन्यवाद - मुझे लगा कि 503 के साथ जाने के लिए सबसे अच्छा था; यह समझते हुए भी कि एक Restful प्रकृति के कार्यान्वयन अक्सर HTTP स्थिति कोड के उनके उपयोग की बात आने पर ऊनी होने का बेईमानी से सामना कर सकते हैं। इस पर मेरा व्यक्तिगत दृष्टिकोण प्रोटोकॉल का उपयोग करने के लिए है जब तक कि यह फिट नहीं होता (जो वास्तव में बहुत दुर्लभ है)। इस मामले में, यह निश्चित रूप से करता है!

— एंड्रास जोल्तान

4xx क्लाइंट द्वारा एक त्रुटि को इंगित करता है जिसे उनके द्वारा एक निश्चित कार्रवाई करने के द्वारा तय किया जा सकता है, जबकि 5xx सर्वर पर एक समस्या को इंगित करता है जो क्लाइंट को हल करने में मदद नहीं कर सकता है। तो आपके मामले में, एक 4xx अधिक उपयुक्त है, क्योंकि (i) सर्वर बिल्कुल वैसा ही व्यवहार कर रहा है जैसा कि करना चाहिए, और (ii) क्लाइंट या तो क्रेडिट को धीमा कर सकता है या अधिक क्रेडिट खरीद कर "ठीक" कर सकता है। 429 प्रतिक्रिया के शरीर में सटीक रिज़ॉल्यूशन का संकेत दिया जा सकता है।

— माइक चेम्बरलेन