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




http-status-codes (7)

स्थिति कोड 304 संशोधित नहीं किया गया डुप्लिकेट अनुरोध को स्वीकार्य प्रतिक्रिया भी देगा। यह एक इकाई टैग का उपयोग कर if If-None-Match शीर्षलेख को संसाधित करने के समान है।

मेरी राय में, @ Piskvor का उत्तर जो मुझे लगता है, वह मूल प्रश्न का इरादा है, लेकिन मेरे पास एक विकल्प है जो प्रासंगिक भी है।

यदि आप एक डुप्लिकेट अनुरोध को किसी त्रुटि के बजाय चेतावनी या अधिसूचना के रूप में देखना चाहते हैं, तो 304 प्रतिक्रिया स्थिति कोड को संशोधित नहीं किया गया है और मौजूदा संसाधन की पहचान करने वाले Content-Location शीर्षलेख मान्य होंगे। जब इरादा केवल यह सुनिश्चित करने के लिए होता है कि कोई संसाधन मौजूद है, तो एक डुप्लिकेट अनुरोध एक त्रुटि नहीं बल्कि एक पुष्टि होगी। अनुरोध गलत नहीं है, लेकिन यह केवल अनावश्यक है, और ग्राहक मौजूदा संसाधन का संदर्भ दे सकता है।

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

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

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

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

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


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

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

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


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

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

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


एम्बर-डेटा के ActiveRecord एडाप्टर को सर्वर से वापस आने के लिए 422 UNPROCESSABLE ENTITY अपेक्षा है। इसलिए, यदि आप ग्राहक हैं Ember.js में लिखे गए हैं तो आपको 422 का उपयोग करना चाहिए। केवल तभी डीएस। त्रुटि लौटाई गई त्रुटियों के साथ आबादी होगी। आप निश्चित रूप से 422 को अपने एडाप्टर में किसी अन्य कोड में बदल सकते हैं


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 )।


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

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

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

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

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

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





http-status-codes