सामान्य असफल अनुरोध (त्रुटि नहीं) के लिए उपयुक्त HTTP स्थिति कोड प्रतिक्रिया क्या है?

109

मैं एक RESTful API बना रहा हूं, जो संग्रहीत क्रेडिट कार्ड का उपयोग करके ऑर्डर रखने सहित कई उपयोगकर्ता इंटरैक्शन को संसाधित करेगा।

एक सफल आदेश के मामले में, मैं 200 ओके वापस कर रहा हूं, और उस मामले में जहां ऑर्डर अनुरोध विकृत है या अमान्य है, मैं 400 बैड अनुरोध वापस कर रहा हूं। लेकिन ऑर्डर के वास्तविक प्रसंस्करण के दौरान कोई समस्या होने पर मुझे क्या करना चाहिए?

क्लाइंट POSTS एक उपयोगकर्ता संसाधन के लिए सर्वर के लिए आदेश। यदि उपयोगकर्ता मौजूद नहीं है, तो 404 नहीं मिला है।
आदेश प्रारूप और सूचना मान्य है। यदि मान्य नहीं है, तो 400 खराब अनुरोध वापस किया जाता है।
आदेश पर कार्रवाई की जाती है। यदि आदेश सफल होता है, तो आदेश के लिए एक 201 बनाया गया वापस कर दिया जाता है। यदि कोई अनपेक्षित त्रुटि आई है, तो 500 सर्वर त्रुटि लौटा दी जाती है।

अंतिम चरण समस्या है - यदि किसी अन्य कारण से ऑर्डर पूरा नहीं होता है तो मैं क्या लौटाऊंगा? संभावित परिदृश्यों में शामिल हो सकते हैं:

उत्पाद बाहर बेचा जाता है
उपयोगकर्ता अधिकतम आदेश सीमा तक पहुँच गया
क्रेडिट कार्ड लेनदेन विफलता (अपर्याप्त धन, आदि)

ऐसा नहीं लगता है कि यह 400 या 500 में से किसी के लिए भी उपयुक्त होगा। यदि कोई चीज मुझे 400 के रूप में दिखाई दे सकती है यदि कोई बेहतर कोड नहीं है - तो व्यापार नियमों के अनुसार अनुरोध अमान्य था। यह सिर्फ सटीक नहीं लगता है।

संपादित करें: एक ही विषय की यह मौजूदा चर्चा भी मिली । वहाँ के सभी उत्तर इस प्रकार के उल्लंघन के लिए स्थिति कोड का उपयोग करने के लिए इंगित करते हैं, 400, 409, या 422 एक्सटेंशन का उपयोग करने के बीच कुछ चर्चा के साथ।

http rest http-status-codes

— Raelshark
स्रोत

8

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

— house9

इससे पहले कि आप 422 में कूदें, विचार करें कि क्या आप WebDAV क्षमताओं का समर्थन करते हैं

— Mbithy Mbithy

90

आपको व्यावसायिक नियमों के लिए 400 का उपयोग करना चाहिए। यदि आदेश स्वीकार नहीं किया गया तो 2xx वापस न करें। HTTP एक एप्लिकेशन प्रोटोकॉल है, इसे कभी न भूलें। यदि आप 2xx लौटाते हैं, तो ग्राहक मान सकता है कि आदेश को स्वीकार कर लिया गया है, फिर चाहे आप किसी भी जानकारी को शरीर में भेजें।

से RESTful वेब सेवाओं कुकबुक :

एक सामान्य गलती जो कुछ वेब सेवाएं करती हैं, एक स्थिति कोड को वापस करना है जो सफलता को दर्शाता है (स्थिति कोड 200 से 206 और 300 से 307 तक) लेकिन इसमें एक संदेश निकाय शामिल है जो एक त्रुटि स्थिति का वर्णन करता है। ऐसा करने से HTTP- जागरूक सॉफ़्टवेयर त्रुटियों का पता लगाने से रोकता है। उदाहरण के लिए, एक कैश इसे सफल प्रतिसाद के रूप में संग्रहीत करेगा और बाद के क्लाइंट को भी इसकी सेवा देगा, जब क्लाइंट एक सफल अनुरोध करने में सक्षम हो सकते हैं।

मैं इसे 4xx और 5xx के बीच तय करने के लिए आपको छोड़ दूँगा, लेकिन आपको एक त्रुटि स्थिति कोड का उपयोग करना चाहिए।

— मैक्स टोरो
स्रोत

1

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

— रालेशक

ये बिल्कुल सही है।

— युवा ह्यून यू

2

क्या आपका मतलब है, 'आपको व्यावसायिक नियमों के लिए 4xx का उपयोग करना चाहिए'?

— यवर

28

क्लाइंट त्रुटि के लिए आपको 4xx का उपयोग करना चाहिए यदि क्लाइंट त्रुटि के आसपास प्राप्त करने के लिए अनुरोध को संशोधित कर सकता है। सर्वर त्रुटि के लिए 5xx का उपयोग करें जो क्लाइंट वास्तव में काम नहीं कर सकता है।

बिकने वाला उत्पाद एक सर्वर त्रुटि होगी। क्लाइंट त्रुटि के आसपास प्राप्त करने के लिए कुछ फैशन में अनुरोध को संशोधित नहीं कर सकता है। आप किसी अन्य उत्पाद पर जा सकते हैं, लेकिन यह एक नया अनुरोध नहीं होगा?

उपयोगकर्ता की अधिकतम आदेश सीमा भी एक सर्वर त्रुटि है। क्लाइंट उस त्रुटि के आसपास काम करने के लिए कुछ नहीं कर सकता।

क्रेडिट कार्ड लेनदेन की विफलता एक ग्राहक त्रुटि होगी। क्लाइंट त्रुटि के चारों ओर काम करने के लिए एक अलग भुगतान विधि या क्रेडिट कार्ड नंबर के साथ अनुरोध को फिर से सबमिट कर सकता है।

— पॉल मॉर्गन
स्रोत

6

यदि ऑर्डर की सीमा पूरी हो गई है, तो क्या ग्राहक को उपयोगकर्ता को इसके प्रति सचेत नहीं करना चाहिए और उन्हें अपने अनुरोध को उचित रूप से बदलने देना चाहिए? यह एक 4xx त्रुटि की तरह लगता है। उसी उत्पाद को बेचा जा रहा है। 5xx त्रुटियों का अर्थ उन त्रुटियों के लिए है जो किसी तरह से सिस्टम के टूटने के कारण होती हैं, न कि किसी व्यवसाय नियम द्वारा अस्वीकृत की गई कार्रवाई के लिए।

— carlin.scott

7

मैं ऊपर की टिप्पणी से सहमत हूं। 5xx त्रुटियाँ सर्वर की समस्याएँ होने पर होती हैं। व्यावसायिक नियमों के लिए 4xx त्रुटियां।

— बुध

21

त्रुटि प्रकार:

4×× Client Error

एरर कोड:

422 Unprocessable Entity

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

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

https://httpstatuses.com/422

— stamster
स्रोत

16

मुझे पता है कि यह सवाल पुराना है, लेकिन मैं आज उसी सवाल के साथ आया हूं। यदि मेरा उपयोगकर्ता क्रेडिट से बाहर है, तो मेरे REST API को किस स्थिति कोड में वापस आना चाहिए?

मैं इस ओर झुक जाता हूं 402 Payment Required:

विकिपीडिया के अनुसार :

भविष्य उपयोग के लिए आरक्षित। मूल मंशा यह थी कि इस कोड का उपयोग डिजिटल कैश या माइक्रोपेमेंट स्कीम के कुछ रूप के रूप में किया जा सकता है, लेकिन ऐसा नहीं हुआ है, और इस कोड का आमतौर पर उपयोग नहीं किया जाता है। यदि किसी विशेष डेवलपर ने अनुरोधों पर दैनिक सीमा पार कर ली है तो Google डेवलपर्स API इस स्थिति का उपयोग करता है।

और वास्तव में वे करते हैं :

PAYMENT_REQUIRED (402)

डेवलपर द्वारा निर्धारित दैनिक बजट सीमा समाप्त हो गई है।

अनुरोधित ऑपरेशन के लिए कोटा से अधिक संसाधनों की आवश्यकता होती है। ऑपरेशन पूरा करने के लिए भुगतान आवश्यक है।

अनुरोधित ऑपरेशन को प्रमाणीकृत उपयोगकर्ता से किसी प्रकार के भुगतान की आवश्यकता होती है।

— बेंजामिन
स्रोत

यह सबसे अच्छी तरह से सोचा और तार्किक जवाब है।

— GTodorov

5

कैसे के बारे में 424 Failed Dependency? युक्ति इसका वर्णन करती है:

विधि संसाधन पर निष्पादित नहीं की जा सकी क्योंकि अनुरोधित क्रिया अन्य क्रिया पर निर्भर थी और वह क्रिया विफल रही।

लेकिन यह परिभाषा भी है :

स्थिति कोड 424 को WebDAV मानक में परिभाषित किया गया है और एक ऐसे मामले के लिए है जहां ग्राहक को यह बदलने की आवश्यकता है कि यह क्या कर रहा है - सर्वर को यहां किसी भी समस्या का सामना नहीं करना पड़ रहा है।

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

जहां तक मैं देख सकता हूं, "एक्शन" काफी व्यापक शब्द है, और इसका उपयोग विभिन्न प्रकार की स्थितियों में किया जा सकता है, जिसमें अपर्याप्त स्टॉक, अपर्याप्त क्रेडिट या वेयरहाउस पार्टी रात शामिल हैं।

एक और विकल्प हो सकता है 422 Unprocessable Entity:

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

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

ऐसी वस्तु का अनुरोध करने की कोशिश करना जो स्टॉक से बाहर हो, या जब आपके पास अपर्याप्त क्रेडिट हो, तो शब्दार्थ स्तर पर गलती मानी जा सकती है।

MozDev का कहना है कि यह क्लाइंट की तरफ से गलती को इंगित करता है, विशेष रूप से: क्लाइंट को बिना संशोधन के इस अनुरोध को नहीं दोहराना चाहिए।

इनपुट सत्यापन विफल होने पर लूपबैक 4 422 का उपयोग करता है।

यकीनन, अपर्याप्त स्टॉक या वेयरहाउस पार्टी की रात को अस्थायी राज्य माना जा सकता है, इसलिए बाद में अनुरोध को फिर से वापस लिया जा सकता है। उस स्थिति को इंगित किया जा सकता है503 Service Unavailable

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

अनुरोध भेजने से पहले ग्राहक को उचित समय का सुझाव देने के लिए सर्वर M एक रिट्री-आफ्टर हेडर फ़ील्ड भेजते हैं।

— joeytwiddle
स्रोत

उनमें से कोई भी भुगतान से संबंधित नहीं है। मैं पिछले जवाब से 402 के साथ जा रहा हूँ!

— GTodorov

2

मुझे नहीं लगता कि सभी व्यावसायिक परिदृश्य के लिए 400 का उपयोग किया जा सकता है। इसका उपयोग मूल डेटा इनपुट सत्यापन के लिए किया जा सकता है। इस त्रुटि कोड में अन्य व्यावसायिक तर्क फिट करने के लिए हमारे पास कठिन समय हो सकता है। इसके द्वारा नियंत्रित की जाने वाली त्रुटि ज्यादातर डिज़ाइन टाइम त्रुटियां होती हैं जो डेवलपर क्लाइंट के कोडिंग के दौरान संभवतः सामना करेंगे।

मान लें कि सभी पैरामीटर सही हैं और मान लें कि हम अनुरोध में उपयोगकर्ता खाता संख्या पास कर रहे हैं।

इसलिए अनुरोध अब बुरा अनुरोध नहीं है, सर्वर अनुरोध को स्वीकार करने में सक्षम है। लेकिन अब यह उपलब्ध नई जानकारी के आधार पर अनुरोध को पूरा करने से इनकार कर रहा है जो कि है - खाते में पर्याप्त संतुलन नहीं है।

मेरा सुझाव है कि हमें उन परिदृश्यों में उपयुक्त त्रुटि संदेश के साथ 403 का उपयोग करना चाहिए।

अन्य संभावित त्रुटि कोड 409 संघर्ष हो सकता है। लेकिन इसका उपयोग उन परिदृश्यों में किया जाता है जहां संसाधन सुसंगत स्थिति में है।

— राजेन्द्र सैनी
स्रोत

-1

मैं 406 के साथ जाता हूं Not Acceptable।

यहाँ एक 4xx सूची है:

const HTTP_BAD_REQUEST = 400;
const HTTP_UNAUTHORIZED = 401;
const HTTP_PAYMENT_REQUIRED = 402;
const HTTP_FORBIDDEN = 403;
const HTTP_NOT_FOUND = 404;
const HTTP_METHOD_NOT_ALLOWED = 405;
const HTTP_NOT_ACCEPTABLE = 406;
const HTTP_PROXY_AUTHENTICATION_REQUIRED = 407;
const HTTP_REQUEST_TIMEOUT = 408;
const HTTP_CONFLICT = 409;
const HTTP_GONE = 410;
const HTTP_LENGTH_REQUIRED = 411;
const HTTP_PRECONDITION_FAILED = 412;
const HTTP_REQUEST_ENTITY_TOO_LARGE = 413;
const HTTP_REQUEST_URI_TOO_LONG = 414;
const HTTP_UNSUPPORTED_MEDIA_TYPE = 415;
const HTTP_REQUESTED_RANGE_NOT_SATISFIABLE = 416;
const HTTP_EXPECTATION_FAILED = 417;
const HTTP_I_AM_A_TEAPOT = 418;                                               // RFC2324
const HTTP_MISDIRECTED_REQUEST = 421;                                         // RFC7540
const HTTP_UNPROCESSABLE_ENTITY = 422;                                        // RFC4918
const HTTP_LOCKED = 423;                                                      // RFC4918
const HTTP_FAILED_DEPENDENCY = 424;                                           // RFC4918
const HTTP_RESERVED_FOR_WEBDAV_ADVANCED_COLLECTIONS_EXPIRED_PROPOSAL = 425;   // RFC2817
const HTTP_UPGRADE_REQUIRED = 426;                                            // RFC2817
const HTTP_PRECONDITION_REQUIRED = 428;                                       // RFC6585
const HTTP_TOO_MANY_REQUESTS = 429;                                           // RFC6585

— महमूद ज़ाल्ट
स्रोत

8

हालांकि स्टेटस कोड 406 का नाम अपने आप में सटीक लग सकता है, आपको इस बात की जानकारी होनी चाहिए कि प्रत्येक स्टेटस कोड में एक आधिकारिक पाठ विवरण होता है। स्थिति कोड 406 के लिए विवरण हाथ में मामले के लिए उपयुक्त नहीं है । उदाहरण के लिए httpstatuses.com/406 देखें ।

— ज़ीरो 3

1

@ Zero3 सही है, इस कोड का मतलब प्रतिक्रिया प्रकार के रूप में वहाँ के बीच स्वीकार हेडर क्लाइंट की ओर से भेजा गया था और MediaType (रों) endpoint द्वारा भेजे गए, जैसे आवेदन / json बनाम पाठ / सादे एक बेमेल है, स्वीकार्य नहीं है

— ग्रेगर