असफल सत्यापन या अमान्य डुप्लिकेट के लिए REST HTTP स्थिति कोड




http-status-codes (6)

200,300, 400, 500 सभी बहुत सामान्य हैं। यदि आप जेनेरिक चाहते हैं, तो 400 ठीक है।

422 का उपयोग एपीआई की बढ़ती संख्या से किया जाता है, और इसका उपयोग रेल द्वारा बॉक्स के बाहर भी किया जाता है।

कोई फर्क नहीं पड़ता कि आप अपने एपीआई के लिए कौन सा स्टेटस कोड चुनते हैं, कोई असहमत होगा। लेकिन मैं 422 पसंद करता हूं क्योंकि मुझे लगता है कि '400 + टेक्स्ट स्टेटस' बहुत सामान्य है। इसके अलावा, आप JSON- तैयार पार्सर का लाभ नहीं ले रहे हैं; इसके विपरीत, एक JSON प्रतिक्रिया के साथ एक 422 बहुत स्पष्ट है, और त्रुटि जानकारी का एक बड़ा सौदा व्यक्त किया जा सकता है।

जेएसओएन प्रतिक्रिया के बारे में बात करते हुए, मैं इस मामले के लिए रेल त्रुटि प्रतिक्रिया पर मानकीकृत करता हूं, जो है:

{
    "errors" :
    { 
        "arg1" : ["error msg 1", "error msg 2", ...]
        "arg2" : ["error msg 1", "error msg 2", ...]
    }
}

यह प्रारूप फॉर्म सत्यापन के लिए एकदम सही है, जिसे मैं 'त्रुटि रिपोर्टिंग समृद्धि' के संदर्भ में समर्थन करने के लिए सबसे जटिल मामला मानता हूं। यदि आपकी त्रुटि संरचना यह है, तो यह आपकी सभी त्रुटि रिपोर्टिंग आवश्यकताओं को संभालने की संभावना होगी।

मैं एक आरईएसटी-आधारित एपीआई के साथ एक एप्लीकेशन बना रहा हूं और उस बिंदु पर आया हूं जहां मैं प्रत्येक अनुरोध के लिए स्टेटस कोड निर्दिष्ट कर रहा हूं।

प्रमाणीकरण में विफल अनुरोधों के लिए मुझे किस स्थिति कोड को भेजना चाहिए या जहां अनुरोध मेरे डेटाबेस में डुप्लिकेट जोड़ने का प्रयास कर रहा है?

मैंने http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html देखा है लेकिन उनमें से कोई भी सही नहीं लगता है।

स्थिति कोड भेजते समय क्या कोई आम प्रथा है?


इनपुट सत्यापन विफलता के लिए: 400 खराब अनुरोध + आपका वैकल्पिक विवरण। यह " रीस्टफुल वेब सर्विसेज " पुस्तक में सुझाया गया है। डबल सबमिट के लिए: 40 9 संघर्ष

जून 2014 अपडेट करें

प्रासंगिक विनिर्देश RFC2616 , जिसने 400 (खराब अनुरोध) का उपयोग अपेक्षाकृत कम किया था

दुर्भावनापूर्ण वाक्यविन्यास के कारण सर्वर द्वारा अनुरोध को समझा नहीं जा सका

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

क्लाइंट त्रुटि होने के कारण सर्वर किसी अनुरोध के कारण अनुरोध को संसाधित नहीं कर सकता या नहीं करेगा


डेटाबेस में डुप्लिकेट 409 CONFLICT होना चाहिए।

मैं सत्यापन त्रुटियों के लिए 422 UNPROCESSABLE ENTITY का उपयोग करने की सलाह देता हूं।

मैं यहां 4xx कोड का लंबा स्पष्टीकरण देता हूं: http://parker0phil.com/2014/10/16/REST_http_4xx_status_codes_syntax_and_sematics/


मैं स्टेटस कोड 422, "अप्राप्य इकाई" की अनुशंसा करता हूं।

11.2। 422 अप्राप्य संस्था

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


200

उह ... (30 9, 400, 403, 40 9, 415, 422) ... बहुत सारे उत्तर अनुमान लगाने, तर्क देने और मानकीकृत करने के लिए एक सफल http अनुरोध के लिए सबसे अच्छा रिटर्न कोड क्या है लेकिन एक असफल विश्राम कॉल

HTTP प्रोटोकॉल कोड और आरईएसटी परिणामों को मिश्रण करना गलत है।

हालांकि, मैंने उन्हें कई मिश्रणों को मिलाकर देखा, और कई डेवलपर मुझसे सहमत नहीं हो सकते हैं।

HTTP रिटर्न कोड HTTP Request से संबंधित हैं। एक आरईएसटी कॉल एक हाइपरटेक्स्ट ट्रांसफर प्रोटोकॉल अनुरोध का उपयोग करके किया जाता है और यह आरईएसटी विधि को बुलाए जाने से कम स्तर पर काम करता है। आरईएसटी एक अवधारणा / दृष्टिकोण है, और इसका उत्पादन एक व्यवसाय / तार्किक परिणाम है, जबकि HTTP परिणाम कोड एक परिवहन है।

उदाहरण के लिए, जब आप कॉल करते हैं / उपयोगकर्ता / भ्रमित होते हैं, तो "404 नहीं मिला" लौटाते हैं, क्योंकि इसका अर्थ यह हो सकता है:

  • यूआरआई गलत है (HTTP)
  • कोई उपयोगकर्ता नहीं मिला (आरईएसटी)

"403 निषिद्ध / एक्सेस अस्वीकृत" का अर्थ हो सकता है:

  • विशेष अनुमति की आवश्यकता है। ब्राउज़र उपयोगकर्ता / पासवर्ड पूछकर इसे संभाल सकता है। (एचटीटीपी)
  • सर्वर पर कॉन्फ़िगर गलत पहुंच अनुमतियां। (एचटीटीपी)
  • आपको प्रमाणित होने की आवश्यकता है (आरईएसटी)

और सूची '500 सर्वर त्रुटि' (एक अपाचे / Nginx HTTP फेंक त्रुटि या आरईएसटी में एक व्यापार बाधा त्रुटि) के साथ जारी हो सकता है या अन्य HTTP त्रुटियों आदि ...

कोड से, यह समझना मुश्किल है कि विफलता कारण, HTTP (परिवहन) विफलता या एक REST (तार्किक) विफलता क्या थी।

यदि HTTP अनुरोध को सफलतापूर्वक निष्पादित किया गया था तो इसे हमेशा 200 कोड वापस करना चाहिए, भले ही रिकॉर्ड (ओं) मिले या नहीं। चूंकि यूआरआई संसाधन पाया जाता है और http सर्वर द्वारा संभाला जाता है। हां, यह एक खाली सेट वापस कर सकता है। 200 के साथ http परिणाम के रूप में एक खाली वेब पेज प्राप्त करना संभव है, है ना?

इसके बजाय आप कुछ विकल्पों के साथ 200 HTTP कोड वापस कर सकते हैं:

  • JSON परिणाम में "त्रुटि" ऑब्जेक्ट अगर कुछ गलत हो जाता है
  • यदि कोई रिकॉर्ड नहीं मिला तो खाली JSON सरणी / ऑब्जेक्ट
  • एक बेहतर हैंडलिंग के लिए पिछले विकल्पों के साथ संयोजन में एक बूल परिणाम / सफलता ध्वज।

साथ ही, कुछ इंटरनेट प्रदाता आपके अनुरोधों को रोक सकते हैं और आपको 404 http कोड लौटा सकते हैं। इसका मतलब यह नहीं है कि आपका डेटा नहीं मिला है, लेकिन परिवहन स्तर पर यह कुछ गलत है।

Wiki :

जुलाई 2004 में, यूके दूरसंचार प्रदाता बीटी समूह ने क्लीनफीड सामग्री अवरोधन प्रणाली तैनात की, जो इंटरनेट वॉच फाउंडेशन द्वारा संभावित रूप से अवैध रूप से अवैध सामग्री के लिए किसी भी अनुरोध के लिए 404 त्रुटि देता है। अन्य आईएसपी एक ही परिस्थितियों में HTTP 403 "वर्जित" त्रुटि लौटाते हैं। थाईलैंड और ट्यूनीशिया में सेंसरशिप को छुपाने के साधन के रूप में नकली 404 त्रुटियों को नियोजित करने का अभ्यास भी किया गया है। ट्यूनीशिया में, जहां 2011 की क्रांति से पहले सेंसरशिप गंभीर थी, लोग नकली 404 त्रुटियों की प्रकृति से अवगत हो गए और "अम्मर 404" नामक एक काल्पनिक चरित्र बनाया जो "अदृश्य सेंसर" का प्रतिनिधित्व करता है।

इस तरह कुछ के साथ जवाब क्यों नहीं देते?

{
  "result": false,
  "error": {"code": 102, "message": "Validation failed: Wrong NAME."}
}

  • विफल सत्यापन: 403 निषिद्ध ("सर्वर अनुरोध को समझ गया, लेकिन इसे पूरा करने से इंकार कर रहा है")। लोकप्रिय राय के विपरीत, आरएफसी 2616 यह नहीं कहता है कि "403 केवल असफल प्रमाणीकरण के लिए है", लेकिन "403: मुझे पता है कि आप क्या चाहते हैं, लेकिन मैं ऐसा नहीं करूंगा"। प्रमाणीकरण के कारण यह स्थिति हो सकती है या नहीं भी हो सकती है।
  • डुप्लिकेट जोड़ने का प्रयास कर रहा है: 40 9 संघर्ष ("संसाधन की वर्तमान स्थिति के साथ संघर्ष के कारण अनुरोध पूरा नहीं हो सका।")

आपको प्रतिक्रिया शीर्षकों और / या शरीर में एक और विस्तृत स्पष्टीकरण देना चाहिए (उदाहरण के लिए कस्टम हेडर के साथ - X-Status-Reason: Validation failed )।







http-status-codes