एक सत्यापन जांच के लिए HTTP 409 उपयुक्त है?

Question

मेरे पास एक ऐसी सेवा है जहां किसी विशेष ऑपरेशन होने से पहले कुछ सत्यापन नियमों की जांच की जानी चाहिए।

उदाहरण के लिए, क्लाइंट को प्रिंट करने योग्य रिपोर्ट नहीं उत्पन्न करनी चाहिए यदि सभी सत्यापन नियमों को पूरा नहीं किया जा रहा है।

हालांकि, एक व्यक्तिगत ग्राहक के पास सभी आवश्यक जानकारी नहीं हो सकती है (वह उपयोगकर्ता केवल सत्यापन की सफलता निर्धारित करने के लिए उपयोग किए जाने वाले डेटा के उप-समूह तक पहुंचने में सक्षम हो सकता है), तो अनुरोध सर्वर पर भेजा जाना चाहिए: मूल रूप से "thingstart और finish के बीच मान्य है"।

प्रतिक्रिया या तो कुछ प्रकार का टोकन होगा जो VALID: FEEL FREE TO CONTINUE इंगित करता है, या सत्यापन विफलता कारणों की एक सूची, जिसे उपयोगकर्ता को प्रस्तुत किया जा सकता है।

यह स्पष्ट है कि एक सफल सत्यापन 200 OK लौटाएगा। लेकिन मुझे नहीं लगता कि एक सफलता स्थिति कोड सत्यापन विफलता के लिए उपयुक्त है। मैं 409 Conflict की ओर झुका रहा हूं, लेकिन मैंने कभी भी PUT या POST को अस्वीकार करने के लिए इसका उपयोग किया है। क्या यह 409 द्वारा संकेतित सत्यापन विफलता के लिए वैध (स्निकर) है, या क्या कोई बेहतर तरीका है?

नोट: कार्यवाही की जा रही कार्रवाई के मामले में 403 के साथ, इस जांच को छोड़कर कार्रवाई की कोशिश की जा रही है, और कार्रवाई का प्रयास करने का विकल्प एक विकल्प नहीं है।

Answer 1

आपने सत्यापन करने के लिए सर्वर से अनुरोध भेजा है। यह सत्यापन सफलतापूर्वक कहा गया है। एक HTTP परिप्रेक्ष्य से, अनुरोध अच्छी तरह से गठित और सर्वर द्वारा सही ढंग से संसाधित किया गया था।

तो मैं कहूंगा कि किसी भी HTTP त्रुटि कोड को वापस करना गलत होगा।

---

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

क्लाइंट के साथ इस अनुरोध को भेजने में बिल्कुल कुछ भी गलत नहीं था।

सर्वर अनुरोध को समझ गया।

अनुरोध मान्य था (एक HTTP परिप्रेक्ष्य से)।

सर्वर अनुरोध को संसाधित कर सकता है।

सर्वर ने उस गतिविधि का 100% प्रदर्शन किया जो इसका मतलब था और अनुरोध संसाधित किए गए परिणामों को वापस कर रहा है।

और यही कारण है कि, जैसा कि मैंने कहा, मुझे विश्वास नहीं है कि एक HTTP त्रुटि कोड उचित है।

आईई। कल्पना करें कि सर्वर एक एंडपॉइंट का खुलासा करता है जो ईमेल पते को मान्य करता है (जो भी विशेष रूप से आप कहना चाहते हैं कि सत्यापन किया जा सकता है)। यह "abc@invalid.org मान्य करें" कहने का अनुरोध प्राप्त करता है और यह एक प्रतिक्रिया उत्पन्न करता है कि "मैंने इस ईमेल पते पर एक नज़र डाली और मैं चाहता हूं कि आप उपयोगकर्ता को यह बताने के लिए कि मुझे अमान्य के लिए वैध DNS प्रतिक्रिया नहीं मिल रही है .org "। अगर लोगों को लगता है कि 200 प्रतिक्रिया सही नहीं है, तो मैं उनके तर्क को समझने के लिए प्यार प्यार करता हूं।

Answer 2

मुझे लगता है कि जब तक आप किसी चीज़ के लिए किसी कोड का दुरुपयोग नहीं कर रहे हैं, तो यह वास्तव में वरीयता और राय के लिए नीचे आता है। प्रमाणीकरण विफलता के लिए उपयोग करने के लिए 40 9 शायद ठीक है, हालांकि मुझे लगता है कि मैं व्यक्तिगत रूप से प्रतिक्रिया के रूप में सत्यापन त्रुटि के साथ 200 पसंद करूंगा। मुझे लगता है कि डेवलपर्स के लिए 401 या 500 जैसी सामान्य संचार त्रुटियों की जांच करना और उनके द्वारा भेजे गए डेटा को सत्यापित करने के बारे में चिंता करने से पहले उनके साथ सौदा करना आसान बनाता है।

Answer 3

हालांकि यह एक प्रस्तावित मानक में अभी भी परिभाषित किया गया है, 422 Unprocessable Entity एक उचित स्थिति है।

422 (संसाधन अयोग्य इकाई) स्थिति कोड का अर्थ सर्वर अनुरोध इकाई (इसलिए एक 415 (असमर्थित मीडिया प्रकार) स्थिति कोड अनुचित है) की सामग्री प्रकार समझता है, और अनुरोध इकाई के वाक्य रचना सही है (इस प्रकार एक 400 (खराब अनुरोध) स्थिति कोड अनुचित है) लेकिन निहित निर्देशों को संसाधित करने में असमर्थ था।

उदाहरण के लिए, यह त्रुटि स्थिति तब हो सकती है जब कोई XML अनुरोध निकाय अच्छी तरह से गठित (यानी, वाक्य रचनात्मक रूप से सही) होता है, लेकिन अर्थात् ग़लत, एक्सएमएल निर्देश।

संदर्भ:

• https://tools.ietf.org/html/rfc4918#section-11.2
• http://developer.github.com/v3/#client-errors
• https://stackoverflow.com/a/2657624/247702
• http://en.wikipedia.org/wiki/List_of_HTTP_status_codes#4xx_Client_Error

Answer 4

अपने HTTP संसाधन की स्थिति कहीं है "यदि जो शुरू nd फिनिश "इस स्वीकार्य पुराने प्रश्न पर अपने शब्दों को समझाने के लिए, मैं 202 लौटने की स्थिति के लिए वोट देना चाहता हूं। इसका लाभ 2 -" सफलता "प्रकार की प्रतिक्रिया होने का लाभ है, इसलिए एक डंबर क्लाइंट इसे नहीं मान पाएगा टूटा हुआ पृष्ठ, और HTTP 1.1 spec में इसके निर्दिष्ट उद्देश्य की तरह लगता है कि आप क्या चाहते हैं (हालांकि स्थिति कोड परिभाषाओं में से कई बहुत संदिग्ध हैं)।

Specification Link

अंश:

202 Accepted 

The request has been accepted for processing, but the processing has not been 
completed. The request might or might not eventually be acted upon, as it 
might be disallowed when processing actually takes place... 

The 202 response is intentionally non-committal. Its purpose is to allow a server 
to accept a request for some other process (perhaps a batch-oriented process 
that is only run once per day) without requiring that the user agent's 
connection to the server persist until the process is completed. The entity 
returned with this response SHOULD include an indication of the request's 
current status and either a pointer to a status monitor or some estimate of 
when the user can expect the request to be fulfilled.