एक सर्वर पर व्यावसायिक तर्क त्रुटियों का प्रतिनिधित्व करने के लिए HTTP स्थिति कोड का उपयोग किया जाना चाहिए?

Question

मैं एक सर्वर से क्लाइंट (जेएस एक ब्राउज़र में) के लिए कुछ एपीआई डिज़ाइन के साथ एक चौराहे पर हूं। हम प्रभाव में सुरक्षा लॉक के कारण किसी कार्रवाई की विफलता का प्रतिनिधित्व करने के लिए HTTP 409 संघर्ष का उपयोग करते हैं। Satefy लॉक हमारे ग्राहकों की उत्पादन प्रणाली में गलती से बदलाव करने से देवों को रोकता है। मुझे यह बताने के लिए क्लाइंट पर 409s को थोड़ा और इनायत से निपटने का काम सौंपा गया है कि एक विशेष एपीआई कॉल विफल क्यों हुआ।

मेरा समाधान यह था कि हमारे AJAX कॉल में से किसी एक की विफलता हैंडलर को लपेट दिया जाए, जो क्लाइंट पर एक सूचना प्रदर्शित करेगा जब 409 के कारण कुछ विफल हो जाता है - यह सब ठीक है और अन्य 4XX और 5XX त्रुटियों के साथ अच्छी तरह से काम करता है जो समान तंत्र का उपयोग करते हैं।

एक समस्या उत्पन्न हुई है जहां हमारे मार्ग संचालकों में से एक 409s के साथ प्रतिक्रिया करता है जब एक व्यापार तर्क त्रुटि का सामना करता है - मेरा AJAX आवरण रिपोर्ट करता है कि सुरक्षा लॉक चालू है, जबकि ग्राहक की मौजूदा विफलता हैंडलर रिपोर्ट करता है कि (यह सोचता है) समस्या शरीर पर आधारित है प्रतिक्रिया की। एक सरल समाधान यह होगा कि हैंडलर की प्रतिक्रिया या स्थिति कोड को हम सुरक्षा लॉक का प्रतिनिधित्व करने के लिए बदल दें।

जो मुझे अपने चौराहे पर लाता है: क्या व्यावसायिक तर्क त्रुटियों का प्रतिनिधित्व करने के लिए HTTP स्थिति कोड का भी उपयोग किया जाना चाहिए? यह सवाल उसी मुद्दे को संबोधित करता है जिसका मैं सामना कर रहा हूं लेकिन यह बहुत अधिक लाभ नहीं उठा पाया। जैसा कि लिंक किए गए उत्तर में सुझाया गया है, मैं व्यापार तर्क के भीतर विफलता का प्रतिनिधित्व करने के लिए एक उपयुक्त निकाय के साथ HTTP 200 ओके का उपयोग करने की ओर झुक रहा हूं।

क्या किसी को यहाँ कोई मजबूत राय है? क्या कोई मुझे समझाने में सक्षम है यह विफलता का प्रतिनिधित्व करने का गलत तरीका है?

Comments

मैं एक उत्तर के रूप में अपनी सरल राय पोस्ट करने में संकोच करता हूं। संक्षेप में: मैं आमतौर पर व्यावसायिक त्रुटियों का प्रतिनिधित्व करने के लिए HTTP स्थिति कोड का उपयोग करने से बचता हूं। उन्हें केवल क्लाइंट और सर्वर के बीच संचार की स्थिति से संबंधित होना चाहिए। सत्यापन या व्यावसायिक तर्क त्रुटियों की वापसी के लिए एक अनुकूल स्थिति कोड होगा 400 Bad Request। इस अलगाव का कारण यह है कि भविष्य के सिस्टम, देवता या दस्तावेजों के पाठक विश्व-व्यापी मानक के आपके विचलन से भ्रमित हो सकते हैं।

— इवो ​​कूपन्स

@IvoCoumans: कृपया इसे ^ एक उत्तर दें ताकि मैं इसे बढ़ा सकूं। 400 Bad Requestएक कंबल HTTP कोड के रूप में एक वर्ग के रूप में व्यावसायिक तर्क त्रुटियों को कवर करने के लिए सबसे अच्छा लगता है।

— 9000

व्यक्तिगत वरीयता, लेकिन मैं 400 Bad Requestतब उपयोग करता हूं जब डेटा गायब होता है या पढ़ा / पार्स नहीं किया जा सकता है। यानी अनुरोध डेटा स्वयं किसी तरह से खराब है।

— केसी स्पीकमैन

कृपया "व्यापार तर्क त्रुटि" द्वारा आपके द्वारा बताए गए पर विस्तार करें। यह बेहद अस्पष्ट है। क्या आपके पास ऐसे इनपुट का मतलब है, जो डेटा सत्यापन जांचों के लिए अमान्य है, इनपुट जो उस समय किसी अन्य बिंदु पर मान्य हो सकता है, लेकिन यह वर्तमान स्थिति में अमान्य है, या व्यवसाय तर्क में बग जहां यह वैध इनपुट को अस्वीकार कर रहा है?

— jpmc26

@ jpmc26 मैं जानबूझकर अस्पष्ट किया जा रहा था क्योंकि यह एक सामान्य प्रश्न था। सर्वर ठीक अनुरोध के साथ मुकाबला किया, लेकिन फैसला किया कि क्वेरी / अभिकथन का कोई मतलब नहीं है।

— जो शहनशाह

Answer 1

कैसी मुख्य बिंदु को कवर करता है।

किसी भी वेब एप में मुख्य विचार: आप अपने डोमेन को एक दस्तावेज स्टोर की तरह देखने के लिए अपना रहे हैं। GET / PUT / POST / DELETE और इतने पर दस्तावेज़ स्टोर के साथ बातचीत करने के सभी तरीके हैं।

तो यह सोचने का एक तरीका है कि किस कोड का उपयोग करना है, यह समझना है कि दस्तावेज़ स्टोर में एनालॉग ऑपरेशन क्या है, और यह विफलता उस एनालॉग में क्या दिखाई देगी।

2xx पूरी तरह से अनुपयुक्त है

स्टेटस कोड के 2xx (सफल) वर्ग इंगित करता है कि क्लाइंट का अनुरोध सफलतापूर्वक प्राप्त हुआ, समझा गया, और स्वीकार किया गया।

5xx भी अनुपयुक्त है

5xx (सर्वर त्रुटि) स्थिति कोड का वर्ग इंगित करता है कि सर्वर को पता है कि यह मिटा दिया गया है

इस मामले में, सर्वर ने गलती नहीं की; यह पता है कि आप इस समय उस संसाधन को संशोधित करने वाले नहीं हैं।

व्यावसायिक तर्क त्रुटियां (जिसका अर्थ है कि व्यवसाय अपरिवर्तनीय इस समय प्रस्तावित संपादन की अनुमति नहीं देता है) संभवतः 409 हैं

409 (संघर्ष) स्थिति कोड इंगित करता है कि अनुरोध लक्ष्य संसाधन की वर्तमान स्थिति के साथ संघर्ष के कारण पूरा नहीं हो सका। यह कोड उन स्थितियों में उपयोग किया जाता है जहां उपयोगकर्ता संघर्ष को हल करने में सक्षम हो सकता है और अनुरोध को फिर से सबमिट कर सकता है। सर्वर SHOULD एक पेलोड उत्पन्न करता है जिसमें एक उपयोगकर्ता के लिए संघर्ष के स्रोत को पहचानने के लिए पर्याप्त जानकारी शामिल होती है।

इस अंतिम बिट पर ध्यान दें - 409 प्रतिक्रिया के पेलोड को उपभोक्ता को जानकारी के बारे में जानकारी देना चाहिए कि क्या गलत हुआ है, और आदर्श रूप से हाइपरमीडिया नियंत्रण शामिल हैं जो उपभोक्ता को उन संसाधनों तक ले जाते हैं जो संघर्ष को हल करने में मदद कर सकते हैं।

मेरा समाधान यह था कि हमारे AJAX कॉल में से किसी एक की विफलता हैंडलर को लपेट दिया जाए, जो क्लाइंट पर एक सूचना प्रदर्शित करेगा जब 409 के कारण कुछ विफल हो जाता है - यह सब ठीक है और अन्य 4XX और 5XX त्रुटियों के साथ अच्छी तरह से काम करता है जो समान तंत्र का उपयोग करते हैं।

और मैं इसे समस्या के रूप में इंगित करूंगा; क्लाइंट पर आपके कार्यान्वयन ने मान लिया कि स्थिति कोड समस्या को परिभाषित करने के लिए पर्याप्त था। इसके बजाय, आपके क्लाइंट कोड को पेलोड की समीक्षा करनी चाहिए, और वहां उपलब्ध जानकारी पर कार्य करना चाहिए।

यही है, आखिरकार, एक दस्तावेज़ स्टोर कैसे करेगा

409  Conflict

your proposed change has been declined because ${REASON}.  
The following resolution protocols are available: ${LINKS[@]})

एक के साथ एक ही दृष्टिकोण 400 Bad Requestभी स्वीकार्य होगा; जो मोटे तौर पर "अनुवाद करता है" आपके अनुरोध के साथ एक समस्या थी। हमें यह पता लगाने के लिए परेशान नहीं किया जा सकता है कि कौन सा स्थिति कोड सबसे अच्छा है, इसलिए यहां आप जाएं। विवरण के लिए पेलोड देखें। "

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

WebDAV विनिर्देश में यह अनुशंसा शामिल है

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

मुझे विश्वास नहीं है कि यह काफी मेल है (हालांकि मैं सहमत हूं कि यह 400एक विकल्प के रूप में कुछ संदेह को बहाता है )। मेरी व्याख्या यह है 422कि "आपने गलत इकाई भेज दी है" जहां 409"आपने गलत समय पर इकाई को भेजा है"।

एक और तरीका रखो, 422अलगाव में माना गया अनुरोध संदेश के साथ एक समस्या को 409इंगित करता है , जहां इंगित करता है कि अनुरोध संदेश संसाधन की वर्तमान स्थिति के साथ संघर्ष करता है।

422 पर चर्चा करने के लिए बेन नडाल की चर्चा उपयोगी हो सकती है।

Comments

" आप अपने डोमेन को एक डॉक्यूमेंट स्टोर की तरह देखने के लिए एडाप्ट कर रहे हैं " - मैं लोगों को इसे पढ़ते हुए देखना पसंद करूंगा, और इससे पहले कि वे (या खिलाफ) रीस्ट के बारे में फैसला करने से पहले पूरी तरह से सभी अनुमानों और निहितार्थों को समझ सकें । वास्तव में।

— जेन्सजी

"व्यावसायिक तर्क त्रुटियां" मुझे "अमान्य इनपुट" की तरह लगती हैं, जो आमतौर पर एक सीधे 400 है, क्योंकि इसके लिए कोई अधिक विशिष्ट त्रुटि कोड नहीं है। यदि यह इनपुट अमान्य नहीं है, तो सर्वर में बग है और 500 उपयुक्त है। आपका उत्तर "व्यापार तर्क त्रुटि" की प्रकृति के बारे में बहुत अधिक लगता है।

— jpmc26

मैं 422 का उपयोग करूंगा। इनपुट वैध है इसलिए 400 का उपयोग करने के लिए सही त्रुटि कोड नहीं है

— कोनराड

Answer 2

मेरे अनुभव में, व्यापार त्रुटियों का प्रतिनिधित्व करने के लिए HTTP त्रुटि कोड अपर्याप्त हैं। हालांकि, वे त्रुटियों के वर्गों का प्रतिनिधित्व करने के लिए उपयोगी हैं।

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

उदाहरण

// error with text response
409 Conflict "safety_lock_engaged"
409 Conflict "customer_not_eligible_for_selected_discount"
// warning with JSON response
202 Accepted { "backorderedProductIds": [ 37, 476 ] }

Comments

400 से ऊपर 4xx की स्थिति कोड के बहुत विशिष्ट अर्थ हैं। यदि आपका मामला विशेष रूप से दूसरों द्वारा कवर नहीं किया गया है तो 400 चुनें।

— jpmc26

@ jpmc26 यदि मैं इस तरह से स्टेटस कोड का उपयोग नहीं करता हूं, तो उनका उपयोग कभी नहीं किया जाता है। लेकिन बेझिझक उन्हें अपने उत्तरों में सही और उचित तरीके का उपयोग करें।

— कासे स्पीकमैन

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

— jpmc26

@ jpmc26 अच्छी तरह से अपवाद का पालन करने के लिए सबसे बड़ा मॉडल नहीं हैं । लेकिन यकीन है, आगे बढ़ो।

— केसी स्पीकमैन

विशिष्ट अपवाद प्रकारों के लिए फेंकना या पकड़ना विशिष्ट HTTP कोड या किसी अन्य त्रुटि कोड का उपयोग न करने का एनालॉग है। मुझे लगा कि यह स्पष्ट होगा। क्या एक अपवाद मॉडल "सर्वश्रेष्ठ" है, इस बिंदु पर पूरी तरह अप्रासंगिक है।

— jpmc26

Answer 3

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

हाल ही में, समान, अनुसंधान में मैंने जो पाया, वह यह था कि आमतौर पर 400 Bad Requestसत्यापन त्रुटियों और इस तरह के उपयोग के लिए स्वीकार किया जाता है । इस तरह, आप सभी व्यावसायिक तर्क त्रुटियों के लिए एक स्थिति कोड का उपयोग करते हैं।

संयोग से, 409इसका उपयोग तब किया जाना चाहिए जब आप इसे संपादित करते समय कोई संसाधन बदल गए हों और इसे फिर से सहेजने का प्रयास किया हो।

Answer 4

आप "खराब अनुरोध" का उपयोग कर सकते हैं और उल्लंघन किए गए व्यापार नियम की आईडी और प्रतिक्रिया के शरीर पर कुछ और विवरण शामिल कर सकते हैं।

Comments

मुझे नहीं पता कि यह मट्ठा था। यह है कि कंपनियों को व्यावसायिक अपवाद कैसे लौट सकते हैं।

— स्केडोश