"योजना सीमा से अधिक" प्रतिक्रिया के लिए अनुशंसित HTTP स्थिति कोड


24

मैं एक ऐसी परियोजना के लिए REST API डिज़ाइन कर रहा हूँ जहाँ उपयोगकर्ता हमेशा कई "योजनाओं" में से एक पर होते हैं - प्रत्येक योजना कुछ संसाधन सीमाओं को परिभाषित करती है, जैसे कि उन उपयोगकर्ताओं की अधिकतम संख्या जिनके पास या उनके द्वारा अपलोड की जा सकने वाली डेटा की अधिकतम संख्या हो सकती है। इन सीमाओं में से एक के पूरा हो जाने के बाद, उपयोगकर्ता अधिक संसाधन प्राप्त करने के लिए अपनी योजनाओं (अनिवार्य रूप से भुगतान) को अपग्रेड कर सकते हैं।

मैं एक विशेष स्थिति कोड को लौटाना चाहता हूं जो ऐसी स्थिति का संकेत देता है जहां खाता संसाधन सीमाओं के कारण कार्रवाई नहीं की जा सकती है, और योजना को अपग्रेड करने से यह हल हो जाएगा - उदाहरण के लिए यदि उपयोगकर्ता अपनी भंडारण क्षमता का 100% उपयोग करता है और एक अतिरिक्त फ़ाइल अपलोड करने का प्रयास करता है , उन्हें यह प्रतिक्रिया मिलेगी।

उम्मीदवार हैं, IMHO:

  • 403 Forbidden - हालांकि, मैं इस मामले और अन्य मामलों के बीच अंतर करना चाहूंगा जहां उपयोगकर्ता के पास इस कार्रवाई को करने की अनुमति नहीं है।

  • 401 Unauthorized - अच्छा विचार नहीं है, हम इसका उपयोग प्रमाणीकरण संबंधी समस्याओं के लिए कर रहे हैं।

  • 402 Payment Required - इस तरह की समझ में आता है, लेकिन मैं एक गैर-मानक अभी तक आरक्षित स्थिति कोड का उपयोग करने के बारे में चिंतित हूं

  • कुछ भी कम मानक जैसे 423 Lockedकि इसकी संभावना नहीं है कि हम इसे भविष्य में किसी और चीज के लिए उपयोग करेंगे

एक अन्य विकल्प कुछ बहुत मानक के साथ जाना है जैसे कि 403लेकिन प्रतिक्रिया शरीर में त्रुटि की बारीकियों को इंगित करें।

मैं सोच रहा हूं कि आपको कौन सा दृष्टिकोण विश्वास है कि (ए) लंबे समय में सबसे अच्छा काम करेगा और (बी) अन्य सिद्धांतों से अधिक अच्छी तरह से चिपक जाएगा।


1
HTTP 507 अपर्याप्त संग्रहण है।
कोडइन्चोस

RFC4331 प्रासंगिक हो सकता है, यह WebDAV के लिए कोटा सीमा के बारे में है।
कोडइन्चोस

@CodesInChaos में यह 5xx त्रुटि नहीं होनी चाहिए, और भंडारण केवल एक उदाहरण था (वास्तविक परियोजना वास्तव में भंडारण के बारे में नहीं है, यह सिर्फ एक अच्छा सादृश्य था)।
शेवर्न

HTTP 429 बहुत अधिक अनुरोध प्रतिक्रिया स्थिति कोड इंगित करता है कि उपयोगकर्ता ने दिए गए समय में बहुत सारे अनुरोध भेजे हैं
ExtractTable.com

जवाबों:


17

मुझे लगता है कि 403 एकमात्र उचित प्रतिक्रिया है, हालांकि 405 विधि अनुमति नहीं है या 409 संघर्ष स्वीकार्य हो सकता है, मुझे नहीं लगता कि 403 के रूप में अच्छे हैं जो कहते हैं:

सर्वर अनुरोध को समझ गया, लेकिन इसे पूरा करने से इनकार कर रहा है। प्राधिकरण मदद नहीं करेगा और अनुरोध को दोहराया नहीं जाना चाहिए। यदि अनुरोध विधि HEAD नहीं थी और सर्वर यह सार्वजनिक करना चाहता है कि अनुरोध क्यों पूरा नहीं हुआ है, तो यह इकाई में इनकार के कारण का वर्णन करेगा

यदि आप 403 त्रुटि लौटाते हैं, तो इसमें कुछ जानकारी शामिल होगी कि संसाधन को अस्वीकार क्यों किया गया था - अमान्य अनुमति केवल सबसे आम मामला है, सीमा से अधिक भिन्न नहीं है - आपकी अनुमति नहीं है क्योंकि आपकी सीमा पार हो गई थी।


22

मेरा मानना ​​है कि 403 गलत है, क्योंकि 403 उन स्थितियों के लिए है, जहां आपको संसाधन तक पहुंच नहीं मिल रही है, और जिस तरह से पहुंच पाने का कोई रास्ता नहीं है। आपके ग्राहकों के लिए, स्पष्ट रूप से पहुंच प्राप्त करने का एक तरीका है: भुगतान करें।

401 वास्तव में गलत है, क्योंकि न केवल आप इसे प्रमाणीकरण के लिए उपयोग कर रहे हैं, लेकिन यह वही है जो इसके लिए है।

चूंकि आप एक एपीआई लिख रहे हैं, मैं मानता हूं कि किसी और को कोड लिखना होगा जो एपीआई का उपयोग करता है, और उस व्यक्ति को आपके एपीआई की युक्ति को पढ़ना होगा। आप 429 "बहुत अनुरोधों" के साथ जा सकते हैं। यह आमतौर पर दर सीमित करने के लिए अभिप्रेत है (जहां एक ग्राहक प्रति दिन 100 अनुरोध कर सकता है, उदाहरण के लिए), लेकिन आपकी स्थिति पर यथोचित लागू होता है। 402 (भुगतान आवश्यक) भी स्वीकार्य होगा, मुझे लगता है। इस बात पर निर्भर करता है कि आप अपने एपीआई का उपयोग करने के लिए लोगों से किन उपकरणों की अपेक्षा करते हैं। 429 में जोखिम है कि एक चतुर उपकरण प्रति मिनट / घंटा / दिन कम अनुरोध भेजने की कोशिश करता है और कभी सफल नहीं होता है।

BTW https://tools.ietf.org/html/rfc6585 के अनुसार 429 त्रुटि में समस्या की प्रकृति का वर्णन करने वाला एक html संदेश भी होना चाहिए, इसलिए एक अच्छा मौका है कि उपयोगकर्ता को वास्तव में बताया जाए कि समस्या क्या है, यदि आप आपूर्ति करते हैं आपकी प्रतिक्रिया में वह जानकारी।


1
402एक विकल्प है, लेकिन मैं 429वास्तविक दरों को सीमित करने के उद्देश्यों के लिए आरक्षित करना चाहता हूं, जिसे हम भविष्य में जोड़ना चाहते हैं
shevron

Google का उपयोग403 करना अच्छा लगता है, हालांकि मुझे 429बहुत अच्छा लगता है। मैंने http क्लाइंट के कुछ कस्टम कार्यान्वयन को देखा है, जिन्होंने कुछ अजीब चीजें कीं 401और 403(उदाहरण के लिए एक वेबसाइट उपयोगकर्ता को लॉग ऑफ कर देती है अगर उसे कभी 401 या एपीआई से 403 मिला)।
क्रिस्टियन व्राबी

0

WebDAV इसके लिए HTTP 507 अपर्याप्त संग्रहण का उपयोग करता है और इसमें कोटा के लिए अतिरिक्त त्रुटि कोड शामिल है, जो इसे अन्य प्रकार की संग्रहण सीमाओं से अलग करने के लिए अनुरोध करता है।


12
ऐसा लगता है कि इसके लिए 5xx कोड का उपयोग करना उचित है।
बेन आरोनसन
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.