"आपके क्षेत्र में सेवा उपलब्ध नहीं" त्रुटि के लिए http स्थिति कोड क्या होना चाहिए?

Question

हमारी सेवा अभी 5 शहरों में है। यदि कोई हमारी सेवा एपीआई को किसी अन्य शहर से कॉल करने का प्रयास करता है, तो हम इस त्रुटि को फेंकना चाहते हैं Service not available in your area।

सवाल यह है कि इस त्रुटि के लिए उपयुक्त http कोड क्या होगा?

• 503 सेवा उपलब्ध नहीं
• 403 निषिद्ध

या कुछ और?

Comments

"अगर कोई हमारी सेवा एपीआई को किसी अन्य शहर से कॉल करने की कोशिश करता है" ध्यान दें कि आईपी जियोलोकेशन बहुत बार गलत है, यदि आप किसी भी उपयोगकर्ता को मना करते हैं जिसका आईपी जियोलोकेशन एक अलग शहर में है तो आप बहुत संभव है कि वैध उपयोगकर्ताओं को बंद कर देंगे।

— पीटर ग्रीन

क्या मुझे अपने बच्चे की सवारी करने की अनुमति नहीं है, जो दूसरे शहर में है और मुझे आने के लिए हवाई अड्डे पर आने की आवश्यकता है?

— दाऊद इब्न करीम

हालांकि सवाल का जवाब नहीं, HTTP 451 (RFC 7725) भविष्य के पाठकों के लिए उपयोगी हो सकता है जो इस प्रश्न को खोजते हैं। यह मुख्य उद्देश्य इंगित करना है कि सामग्री कानूनी अनुरोध, कार्रवाई या प्रतिबंध (कॉपीराइट, अदालत के आदेश आदि) के कारण उपलब्ध नहीं है

— Tyzoid

यदि नेटवर्क कनेक्टिविटी, प्रमाणीकरण, अनुप्रयोग में आंतरिक रूप से कोई त्रुटि नहीं है, और वाक्यात्मक रूप से मान्य इनपुट में कोई त्रुटि संदेश नहीं होना चाहिए। "हम इस क्षेत्र में हमारी सेवा की पेशकश नहीं करते हैं" के साथ आपने प्रौद्योगिकी मुद्दों को छोड़ दिया है और व्यावसायिक मुद्दों में चले गए हैं, इसलिए मुझे यकीन नहीं है कि एक HTTP त्रुटि उचित होगी। मुझे लगता है कि आपको 200 और (या 302 और पुनर्निर्देशित) एक उपयुक्त संदेश देना चाहिए "सॉरी हमारी सेवा आपके क्षेत्र में उपलब्ध नहीं है - अभी तक। लेकिन हम विस्तार कर रहे हैं - 2019 के अंत में वापस जांचें!" या जो भी विपणन विभाग के साथ आता है।

— ivanivan

यह इस सवाल से स्पष्ट नहीं है कि क्या आपका मतलब क्लाइंट कंप्यूटर के स्थान (जियो) के आधार पर एपीआई तक सभी पहुंच को अवरुद्ध करना है या यदि आप किसी विशेष विफल एपीआई अनुरोध के लिए प्रतिक्रिया कोड के लिए पूछ रहे हैं (जैसे पुस्तक? पता = 123_example_st_stondon)? । क्या इनपुट का स्थान हिस्सा है, या क्या आपके पास क्लाइंट का स्थान किसी और तरह से है?

— बेन

Answer 1

कोई भी HTTP त्रुटि कोड अनुचित होगा। HTTP के नजरिए से किसी भी प्रकार की कोई त्रुटि या समस्या नहीं है, इसलिए यह 200 रेंज में कुछ होना चाहिए। आप अपने कुछ उपयोगकर्ताओं को विनम्रता से सूचित करते हैं कि उन्हें एक दस्तावेज वापस भेजने से सेवित नहीं किया जाएगा जो उन्हें बताता है। और यह सब ठीक चलता है।

उपयोगकर्ता आपके एप्लिकेशन का उपयोग नहीं कर पाएगा । यह आपके व्यवसाय तर्क द्वारा किया गया एक सचेत निर्णय है, न कि एक दुर्घटना। HTTP स्तर पर सब कुछ सम्मानजनक है।

संपादित करें

ऐसा लगता है कि हम यहां जो देख रहे हैं वह पुराने स्कूल बनाम नए स्कूल का टकराव है। जब HTTP डिज़ाइन किया गया था, तब कोई वेब सेवा नहीं थी, कोई SOAP नहीं था, कोई JSON नहीं था, कोई REST सिद्धांत नहीं थे। टीसीपी के ऊपर एक प्रोटोकॉल के रूप में यह पहले से ही माना जाता था (आवेदन के करीब) और कई उच्च स्तरीय स्थिति कोड परिभाषित किए गए थे। जब वेब का उपयोग अमीर, उच्च स्तरीय सेवाओं और "लिफाफे" के परिवहन के लिए एक सामान्य साधन के लिए किया जाने लगा, तो डिजाइनरों ने एक नए और क्लीनर प्रोटोकॉल को परिभाषित करने के बजाय HTTP को जैक किया, सिर्फ इसलिए कि HTTP सर्वव्यापी था।

इसलिए एक आधुनिक वेब सेवा के संदर्भ में, HTTP वास्तव में एक डंब ट्रांसपोर्ट परत से थोड़ा अधिक है और इसके अधिकांश कोड लागू या अप्रचलित नहीं माने जा सकते हैं। बस एक को चुनना क्योंकि यह आपकी एप्लिकेशन स्थिति के करीब आता है और उस सूची में होता है कि एक बार मतलब कुछ हानिरहित लग सकता है, लेकिन मुझे लगता है कि यह एक गलत संदेश भेजेगा। आप नहीं चाहते कि HTTP वेब सेवा के संदर्भ में उस विनियमन भूमिका निभाए।

Comments

इस तर्क के द्वारा, किसी भी एप्लिकेशन त्रुटि को 200 के रूप में वापस किया जाना चाहिए। और सभी अनुरोधों को पोस्ट, यहां तक ​​कि हटाए जाने चाहिए। यह दृष्टिकोण HTTP को एक अपारदर्शी परिवहन प्रोटोकॉल के रूप में मानता है - जैसे टीसीपी। यह नहीं है कि आमतौर पर वेब सेवा एपीआई का इलाज कैसे किया जाता है - वे एपीआई के लिए HTTP शब्दार्थ एक मानक भाषा का लाभ उठाने की कोशिश करते हैं। कस्टम, नॉनस्टैंडर्ड एरर कोड के साथ 200 वापस करने के बजाय अनधिकृत के लिए 401 क्यों नहीं?

— अवनर शाहर-कश्तन

इस तर्क से, किसी भी आवेदन को कभी भी 400 की सीमा में कोई प्रतिक्रिया नहीं देनी चाहिए। यह ठीक उसी प्रकार की स्थिति है कि प्रतिक्रियाओं की 400 श्रेणी है। साथ ही, क्या आपका पहला वाक्य भविष्य के सभी उत्तरों पर लागू होता है, साथ ही उन लोगों के लिए भी जो आपके सामने पोस्ट किए गए थे?

— दाऊद इब्न करीम

मुझे इस बात से सहमत होना होगा कि यह केवल एक सादा 200 है। उपयोगकर्ता ने एक प्रश्न पूछा है, हमने इसे समझा, हम सही उत्तर जानते हैं, और हमने उसे उत्तर प्रदान किया है (जो "नहीं" होता है)। HTTP भूमि में सभी अच्छी तरह से है।

— ली डैनियल क्रोकर

हेहे ... "यह वास्तव में एक त्रुटि नहीं है" से त्वरित यात्रा "तो, आप कह रहे हैं कि कुछ भी कभी भी त्रुटि नहीं है?"

— svidgen

इस। "आपने एक URL का उपयोग करने की कोशिश की है जो मौजूद नहीं है" "हमारी कंपनी आपके क्षेत्र में काम नहीं करती है" से बहुत अलग है। केवल एक HTTP के साथ कुछ भी करना है।

— सीजे डेनिस

Answer 2

5xxत्रुटियाँ सर्वर त्रुटियां हैं - सर्वर पर कुछ गलत हुआ। विशेष रूप से, एक 503 इंगित करता है कि:

सर्वर वर्तमान में अस्थायी अधिभार या अनुसूचित रखरखाव के कारण अनुरोध को संभालने में असमर्थ है

4xxत्रुटियाँ क्लाइंट त्रुटियां हैं - क्लाइंट अनुरोध कर रहा है कि सर्वर असमर्थ है या पूरा करने के लिए तैयार नहीं है। विशेष रूप से, एक 403 इंगित करता है कि

सर्वर अनुरोध को समझ गया लेकिन इसे अधिकृत करने से इंकार कर दिया। एक सर्वर जो सार्वजनिक करना चाहता है कि अनुरोध क्यों मना किया गया है, प्रतिक्रिया पेलोड (यदि कोई हो) में उस कारण का वर्णन कर सकता है। [..] हालांकि, क्रेडेंशियल्स से असंबंधित कारणों के लिए एक अनुरोध मना किया जा सकता है।

मेरा तर्क है कि 503यह स्पष्ट रूप से गलत है, क्योंकि यह एक अस्थायी मुद्दा नहीं है - आप उस क्षेत्र, अवधि में अनुरोधों का समर्थन नहीं करते हैं। यह तर्क दिया जा सकता है कि आप अंततः क्षेत्र का समर्थन करने की उम्मीद करते हैं, लेकिन कोड का इरादा एक हेडर को शामिल करना है जो यह संकेत देता है कि ग्राहक फिर से कोशिश कर सकता है। "6 महीने में" इरादे का पालन नहीं करता है।

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

Comments

403 उन मामलों के लिए है जहां पहुंच निषिद्ध है, और क्लाइंट इसके बारे में कुछ नहीं कर सकता है। लेकिन इस मामले में क्लाइंट आपके लैपटॉप या फोन के साथ कार में मिल सकता है), इसलिए 403 अनुचित है।

— gnasher729

@ gnasher729 4xx त्रुटियां उन चीजों के लिए हैं जिन्हें ग्राहक ठीक करने में सक्षम हो सकता है, जिसमें 403 शामिल हैं। (जुड़ा हुआ) विशेष रूप से बताता है कि ग्राहक अलग-अलग क्रेडेंशियल के साथ पुनः प्रयास कर सकता है (क्रेडेंशियल को मुद्दा मानते हुए)।

— jaxad0127

@ gnasher729 403 का मतलब यह नहीं है कि मानव इसके बारे में कुछ नहीं कर सकता है। इसका मतलब है कि ब्राउज़र इसके बारे में कुछ नहीं कर सकता है। मानव हमेशा पासवर्ड रीसेट कर सकता है, व्यवस्थापक से बात कर सकता है या इस मामले में दूसरे शहर में जा सकता है।

— स्लीवेटमैन

@ gnasher729 क्लाइंट उपयोगकर्ता नहीं है।

— कप्तान मैन

5xx = हमारे बुरे को छोड़ देता है, समस्या को ठीक करते समय लटकाए रखता है। 4xx = हमें खेद है लेकिन इस समय हम आपके अनुरोध को समायोजित करने में असमर्थ हैं। यहाँ क्यों ....

— candied_orange

Answer 3

न उन का।

यदि आपका API अच्छी तरह से डिज़ाइन किया गया है, तो URL में शहर का नाम शामिल है, जैसे

http://example.com/API/Vienna/HailRide

या

http://example.com/API/HailRide?city=Vienna

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

एक बार जब आप ऐसा कर लेते हैं, तो सही उत्तर

http://example.com/API/SomeUnsupportedCity/HailRide

या

http://example.com/API/HailRide?city=SomeUnsupportedCity

स्पष्ट हो जाता है: 404 नहीं मिला : SomeUnsupportedCity पर सवारी करने के लिए कोई संसाधन मौजूद नहीं है।

Comments

यह स्वीकृत उत्तर होना चाहिए: एपीआई डिजाइन केवल पुराने संख्यात्मक कोड के अनुपालन के बारे में नहीं है, और वीपीएन आदि के बारे में परिदृश्य काफी यथार्थवादी है।

— एडुआर्डो

मुझे इससे सहमत नहीं होना है। URL में शहर का नाम शामिल करने से सड़क के नीचे सभी प्रकार की समस्याएं हो सकती हैं, क्योंकि यह क्लाइंट को स्थान के आधार पर शहर का नाम निर्धारित करने के लिए मजबूर करता है, और आप अच्छी तरह से परिणाम पसंद नहीं कर सकते हैं। उदाहरण के लिए, क्या आप लॉस एंजिल्स या बेवर्ली हिल्स में हैं? लंदन या वेस्टमिंस्टर? यदि ग्राहक को लगता है कि यह रिचर्डसन में है, तो क्या होगा, लेकिन आप पूरे डलास क्षेत्र में एक एपीआई चाहते हैं? ग्राहक को पिकअप / ड्रॉपऑफ स्थानों की आपूर्ति करना बेहतर होगा; सर्वर यह निर्धारित कर सकता है कि वे सेवा क्षेत्र के भीतर हैं या नहीं और उसी के अनुसार प्रतिक्रिया दें।

— जैच लिप्टन

@ZachLipton मुझे पूरा यकीन है कि शहर के नाम केवल एक उदाहरण थे, यह ओपी के वास्तविक व्यावसायिक नियमों पर निर्भर करता है कि वे "शहर" या "स्थान" कैसे परिभाषित करते हैं। यह एक समन्वय भी हो सकता है।

— बरगी

@ZachLipton नहीं, यहां बिंदु उस स्थान को समझने के लिए सेवा का उपयोग क्लाइंट आईपी नहीं कर रहा है, जो कि सिर्फ गलत है

— एडोआर्डो

@ ईडियस मैं मानता हूं कि क्लाइंट आईपी का उपयोग करना कई कारणों से एक बुरा विचार है। मैं कह रहा हूं कि / API / वियना / हेलराइड भी समस्याओं से ग्रस्त है, क्योंकि इसे क्लाइंट को शहर के नामों में स्थान बदलने की आवश्यकता होती है, और यह 1 से 1 मैपिंग नहीं है जो उन क्षेत्रों से मेल खाती है जो एक कंपनी व्यवसाय करती है।

— जैच लिप्टन

Answer 4

यह एक गोल छेद / वर्ग खूंटी प्रश्न जैसा लगता है। HTTP कोड होने के लिए आपकी एकमात्र प्रतिक्रिया की आवश्यकता क्यों है? HTTP त्रुटि कोड संभवतः सभी उपयोग के मामलों को कवर नहीं कर सकते हैं।

आपके सभी API कॉल में अतिरिक्त मैसेजिंग होनी चाहिए जो वापस आती है - यानी थोड़ा JSON त्रुटि संदेश। उन्हें एक 403 दें (क्योंकि, सही मायने में उनके पास स्थान दिए गए एपीआई का उपयोग करने की अनुमति नहीं है) और सुझाव के रूप में अतिरिक्त जानकारी लौटाएं।

यदि आप ऐसा नहीं करते हैं, तो अगली बार आप पूछेंगे कि जब एसयूवी के लिए उपयोगकर्ता ने पूछा तो HTTP त्रुटि कोड क्या है, लेकिन केवल एक Prius उपलब्ध है।

Comments

अपने अंतिम वाक्य के लिए +1। इसे अच्छी तरह से चूसता है।

— LoztInSpace

अच्छी तरह से यह स्पष्ट रूप से किसी तरह का 3xx पुनर्निर्देशित होना चाहिए। ;)

— ब्रैंडन मिन्टल

आखिरी मामला शायद किसी तरह का 4xx प्रतिक्रिया का वारंट करता है: उपयोगकर्ता ने अनुरोध किया कि सर्वर पूरा नहीं कर सकता है। यदि स्थान स्वयं मौजूद नहीं है तो यह 400 किसी भी तरह का अमान्य इनपुट या 404 होगा। हालाँकि यह 200 हो सकता है यदि यह एक खोज मापदंड है और इसका कोई मिलान नहीं है।

— jpmc26

Answer 5

कुछ समझ में आता है।

403 निषिद्ध, जिन कारणों से एरिक स्टीन ने अपने उत्तर में उल्लेख किया है । आप यह निर्धारित करने के लिए अनुरोध के द्वारा प्रदान की गई विभिन्न जानकारी का उपयोग कर सकते हैं कि ग्राहक कहां है और ग्राहक कौन है और उस अनुरोध के आधार पर, सर्वर जवाब देने में असमर्थ या अनिच्छुक है।

हालांकि, मैं कुछ मामलों के लिए संभावित वापसी की स्थिति के रूप में कानूनी कारणों के लिए 451 अनुपलब्ध को भी आगे रखूंगा। यह स्थिति आपको (शीर्षलेख में) संबंधित कानून की एक कड़ी को शामिल करने की उम्मीद करती है। यह विशेष रूप से उन मामलों के लिए है जहां क्लाइंट के लिए आपके संसाधनों तक पहुंचना कानूनी नहीं है, और क्लाइंट का अधिक सामान्य मामला एक असमर्थित क्षेत्र या क्षेत्र में मौजूद नहीं है।

मैं 5xx सीरीज़ ऑफ स्टेटस से बचूंगा - ये अक्सर सर्वर साइड तकनीकी समस्याओं को दर्शाते हैं। यहाँ ऐसा प्रतीत नहीं होता।

Comments

शायद इस मामले में कारण यह है कि यह उन कारों के बारे में उपयोगकर्ता को बताने का कोई मतलब नहीं है जो उनके शहर में नहीं हैं। तो यह 451 के लिए मामला नहीं है

— अधिकतम 630

@ max630 आप सवाल से यह नहीं मान सकते। 403 निषिद्ध सबसे सही विकल्प है। हालांकि, अगर सेवा पर कानूनी प्रतिबंध हैं, तो इसके बजाय अधिक विशिष्ट 451 का उपयोग किया जा सकता है। 451 को अक्सर विशेष उपयोग के मामलों के लिए 403 के अधिक विशिष्ट संस्करण के रूप में देखा जाता है, इसलिए इसे लाने के लिए समझ में आता है।

— थॉमस ओवेन्स

@ max630 - यह पूरी तरह से संभव है कि यहां 451 उपयुक्त है। कई न्यायालयों को सेवा प्रदान करने से पहले क्षेत्रीय अधिकारियों के साथ पंजीकृत होने के लिए इस तरह की सेवा के ऑपरेटरों की आवश्यकता होती है। वे वास्तव में कुछ अनुरोधों को संसाधित करने से कानूनी रूप से निषिद्ध हो सकते हैं यदि वे क्षेत्र से बाहर निकलते हैं।

— जूल्स

Answer 6

यदि प्रतिबंध कानूनी कारणों के कारण है, तो उचित HTTP त्रुटि कोड HTTP 451 है, "कानूनी कारणों के कारण अनुपलब्ध।"

यह आम तौर पर उत्पीड़न अभियानों या इस तरह के कारण DMCA कार्रवाई या मुकदमों के कारण निरस्त की गई सामग्री के मामले में उपयोग किया जाता है, लेकिन प्रतिक्रिया की स्थिति की भावना और पत्र बताता है:

यह दस्तावेज़ उपयोग के लिए एक हाइपरटेक्स्ट ट्रांसफर प्रोटोकॉल (HTTP) स्थिति कोड निर्दिष्ट करता है जब कानूनी मांगों के परिणामस्वरूप संसाधन पहुंच से इनकार किया जाता है।

कोड ही रे ब्रैडबरी द्वारा फारेनहाइट 451 का संदर्भ है ।

Answer 7

लोग अक्सर भूल जाते हैं कि HTTP स्थिति कोड एक्स्टेंसिबल हैं।

HTTP स्थिति कोड एक्स्टेंसिबल हैं। सभी पंजीकृत स्थिति कोडों के अर्थ को समझने के लिए HTTP एप्लिकेशन की आवश्यकता नहीं है, हालांकि ऐसी समझ स्पष्ट रूप से वांछनीय है। हालाँकि, अनुप्रयोग किसी भी स्थिति कोड के वर्ग को समझते हैं, जैसा कि पहले अंक द्वारा दर्शाया गया है, और किसी भी गैर-मान्यताप्राप्त प्रतिक्रिया को उस वर्ग के x00 स्थिति कोड के समतुल्य मानते हैं, इस अपवाद के साथ कि कोई अपरिचित प्रतिक्रिया आवश्यक नहीं है। उदाहरण के लिए, यदि ग्राहक द्वारा 431 का अपरिचित स्टेटस कोड प्राप्त किया जाता है, तो वह सुरक्षित रूप से यह मान सकता है कि उसके अनुरोध में कुछ गड़बड़ी थी और प्रतिक्रिया को मानें जैसे कि उसे 400 स्टेटस कोड प्राप्त हुआ हो। ऐसे मामलों में, उपयोगकर्ता एजेंट उस उपयोगकर्ता को उपस्थित करते हैं जो प्रतिक्रिया के साथ इकाई को लौटाता है,

https://tools.ietf.org/html/rfc2616#section-6.1.1

आप हमेशा अपने एपीआई और क्लाइंट एप्लिकेशन द्वारा उपयोग के लिए 400 रेंज में अपना स्टेटस कोड बना सकते हैं ।

Comments

हम्म ... यदि अनुरोध में Expect token;city="Albequerque"हेडर शामिल नहीं है, तो यह आवश्यक नहीं है । तब सबसे उपयुक्त प्रतिक्रिया 417 होगी, अपेक्षा विफल हो गई। tools.ietf.org/html/rfc2616#section-10.4.18 यह मानते हुए कि यह वेब सेवा के लिए है।

— बेरिन लोरिट्श

हो सकता है कि आवश्यक न हो @BerinLoritsch, बल्कि किसी मौजूदा कोड में एक स्थिति को फिट करने के लिए मजबूर करने के बजाय, यह सिर्फ एक पंट करने और एक कस्टम का उपयोग करने के लिए बेहतर हो सकता है।

— रबरडक

Answer 8

पहले तो मैंने 503 सोचा क्योंकि विवरण "सेवा अनुपलब्ध" मुद्दे के साथ संरेखित करने के लिए लगता है लेकिन परिभाषाओं को देखते हुए , 503 सर्वर अनुपलब्धता के लिए वास्तव में विशिष्ट है। फिर अधिक सोचने पर, आप क्लाइंट को बता रहे हैं कि अनुरोध के साथ कोई समस्या है, न कि सर्वर साइड समस्या है।

403 करीब है क्योंकि आप उपयोगकर्ता को बता रहे हैं कि आपने संदेश प्राप्त कर लिया है और इसे समझ रहे हैं लेकिन सर्वर इसे संतुष्ट करने के लिए तैयार नहीं है। यह भ्रामक हो सकता है इसलिए परिदृश्य का वर्णन करने के लिए एक पाठ्य विवरण जोड़ा जा सकता है। आरएफसी के अनुसार, 404 भी इस कोड का एक वैध विकल्प है।

जब तक किसी ने इसके लिए एक नया कोड नहीं देखा है, 403 या 404 सबसे नज़दीकी लगते हैं।

Comments

निश्चित रूप से 5xx कोड नहीं है, क्योंकि इसका तात्पर्य है कि बाद में सटीक अनुरोध की कोशिश करना सफल हो सकता है। 4xx कोड निश्चित रूप से क्लाइंट से अनुरोध करता है कि वह कम से कम कुछ अनुरोध (इस मामले में, "सेवा स्थान" फ़ील्ड) को बदले बिना फिर से कोशिश न करे।

— टोबे स्पाइट

Answer 9

आपको उस कोड के साथ त्रुटि के विवरण का मिलान करना चाहिए जो आप दे रहे हैं:

• यदि आप कहते हैं Service not available in your area.तो आपको देना चाहिए 404क्योंकि आप दावा करते हैं कि सेवा उपलब्ध नहीं है ।

• यदि आप कहते हैं You are not authorized for this service in your area.तो आपको 403इसलिए देना चाहिए क्योंकि आप दावा करते हैं कि कॉलर अधिकृत नहीं है ।

मैं दूसरे के लिए जाऊंगा।

Comments

404 उपलब्धता के बारे में नहीं है , यह अस्तित्व के बारे में है । सिर्फ इसलिए कि कुछ परिस्थितियों में एक सेवा उपलब्ध नहीं है, आपको 404 प्रतिक्रिया नहीं देनी चाहिए, जब तक कि आप नहीं चाहते कि लोग यह मान लें कि यह बिल्कुल भी मौजूद नहीं है। इस स्थिति के लिए 404 प्रतिक्रिया निरर्थक होगी।

— जूल्स

@jules 403 (जो पुराना हो सकता है) के लिए युक्ति के अनुसार: "यदि सर्वर ग्राहक को यह जानकारी उपलब्ध नहीं कराना चाहता है, तो इसके बजाय स्थिति कोड 404 (नहीं मिला) का उपयोग किया जा सकता है। " जोर दिया। तो अगर 403 ठीक है, तो 404 भी होगा, लेकिन जरूरी नहीं कि दिए गए कारण के लिए।

— जिमीजम्स

@ जिमीजैम - हाँ, यह विनिर्देश के भीतर है, लेकिन वास्तव में एक बुरा विचार है क्योंकि यह डिबगिंग की समस्याओं को बहुत मुश्किल बना देता है। नहीं कि आप एक एपीआई में क्या चाहते हैं।

— जूल्स

@ जूल्स सेवा कुछ क्षेत्रों में मौजूद नहीं है । बहुत कुछ ऐसे छोटे स्टोर हैं जो केवल मेरे शहर में ही मौजूद हैं, इसलिए किसी दूसरे शहर में उनका पता पूछने पर सही प्रतिक्रिया मिलती है "मौजूद नहीं है।"

— एंडी

एक सेवा url पथ के बारे में "अस्तित्व" के बारे में बात करने वाला ehmm कम से कम - दार्शनिक है, स्पष्टता के लिए एक बार जब आप एक रास्ता प्रकाशित करते हैं तो आपको एक उत्तर प्रदान करना होगा, 403 इस मामले में जाने का तरीका है, जिसमें किसी भी तरह का मौखिक विवरण है स्थिति।

— एडुआर्डो

Answer 10

एक वर्तमान इंटरनेट-ड्राफ्ट है (जो 31 दिसंबर, 2018 को समाप्त हो जाएगा) जो कानूनी कारणों की स्थिति के लिए HTTP 451 अनुपलब्ध संशोधन का प्रस्ताव करता है । मसौदे से पता चलता है कि 451 प्रतिक्रिया में एक geo-scope-blockहेडर होना चाहिए, जो "[ISO.3166-1] में परिभाषित अल्फा -2 देश कोड की अल्पविराम से अलग सूची के अनुरूप होना चाहिए"। हालाँकि, मसौदा यह भी निर्दिष्ट करता है कि कोड 451 का उपयोग "ऑपरेटर द्वारा निर्दिष्ट नीति के अनुसार संसाधन के लिए संसाधन तक पहुँचने से इनकार करने के लिए ऑपरेटर के रूप में नहीं किया जाना चाहिए" (ऑपरेटर पर रखी जा रही कानूनी मांग के विपरीत) "।

इसलिए यह मानते हुए कि आपके पास जियोब्लॉक की कानूनी मांग नहीं है, 451 सही कोड नहीं है। फिर सही कोड क्या है? खैर, कई अन्य जवाब पहले से ही 403 निषिद्ध सुझाए गए हैं , लेकिन वे सभी "राय आधारित" प्रतीत होते हैं, तो चलिए देखते हैं कि अन्य क्या हैं:

• अमेज़न CloudFront 403 निषिद्ध का उपयोग करता है
• ट्विटर जाहिरा तौर पर 200 ठीक देता है, लेकिन JSON सामग्री में इस मामले की व्याख्या करता है - लेकिन यह पूरे एपीआई नहीं बल्कि व्यक्तिगत ट्वीट्स के लिए है
• Pinterest 451 का उपयोग करता है
• वर्डप्रेस आईपी जियो ब्लॉक प्लगइन आपको किसी भी मौजूदा कोड को चुनने की अनुमति देता है

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

मैं कहूंगा कि कस्टम HTTP स्टेटस कोड को निर्दिष्ट करने में कुछ भी गलत नहीं होगा, जैसे कि रबरडक पहले ही उत्तर दे चुका है । 400-रेंज में एक कस्टम स्टेटस कोड वास्तव में एक बहुत अच्छा कॉल हो सकता है, क्योंकि अगर उन्हें "HTTP स्थिति 499" जैसा कुछ दिखाई देता है, तो निश्चित रूप से डेवलपर्स का ध्यान जाएगा। एक "403" को " ओके के रूप में पास करना बहुत आसान है, इसलिए मुझे अपना पासवर्ड गलत मिला, चलो इसके बजाय कुछ और प्रयास करें ", और इसके परिणामस्वरूप घंटों बर्बाद होते हैं।