SOAP दोष या परिणाम वस्तु?

मैं इस बारे में एक सहकर्मी के साथ चर्चा कर रहा था और हम एक समझौते पर नहीं आ सके, इसलिए मैं आपके विचार प्राप्त करना चाहता था। मेरे पास इस पर मेरी राय है, लेकिन मैं इसे आपके लिए खराब नहीं करूंगा।SOAP दोष या परिणाम वस्तु?

जब मैं एक सोप गलती लौट जाना चाहिए और जब मैं एक परिणाम वस्तु त्रुटि जानकारी है कि लौटने किया जाना चाहिए? मान लें कि यह एक सामान्य वेब सेवा के लिए है जिसे विभिन्न प्रणालियों (.NET, जावा, जो कुछ भी) द्वारा उपभोग किया जा सकता है। परिणाम ऑब्जेक्ट में एक एरर ध्वज होगा, एक त्रुटि टाइप (विशिष्ट अपवाद प्रकार के समान), और एक संदेश।

कुछ बिंदुओं पर विचार करने के

एक डेटा सत्यापन त्रुटि एक गलती है?
क्या दोषों (बहुत असाधारण मामलों के लिए) और परिणाम वस्तु ("अपेक्षित" त्रुटियों के लिए) का संयोजन होना चाहिए?
आप SOAP दोषों (महत्वपूर्ण [शून्य संदर्भ] बनाम सत्यापन [ज़िप कोड गलत] कैसे समूहबद्ध करेंगे)?
फेल-उपवास आदि
सर्वश्रेष्ठ अभ्यास, पैटर्न, मानकों त्रुटि के लिए जाँच करने के लिए,

लेख के लिंक मान्य हैं याद करने के लिए बनाम। भले ही यह लग रहा है जैसे मैं आपकी राय चाहते हैं, तथ्यों से चिपके कृपया (एक्स क्योंकि y और z के लिए बेहतर है ...)

स्रोत

2010-05-12 Nelson Rothermel

छह साल बाद मैंने SOAP 1.2 के साथ कुछ नया सीखा है: https://www.w3.org/TR/soap12-part1/#faultcodes एक गलती 'कोड' तत्व में 'प्रेषक' मान हो सकता है जिसे वर्णित किया गया है 'संदेश ... सफल होने के लिए उचित जानकारी नहीं थी। उदाहरण के लिए, संदेश की कमी हो सकती है ... भुगतान जानकारी। यह आमतौर पर एक संकेत है कि संदेश परिवर्तन के बिना नाराज नहीं होना चाहिए। 'ऐसा लगता है कि मेरे लिए डेटा सत्यापन और इस तरह एक संकेत है कि दोषों का उपयोग किया जाना चाहिए। –

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

कहा यही कारण है, एक त्रुटि लौटने आमतौर पर ग्राहक के लिए उपयोगी नहीं है:

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

अपने विशिष्ट जवाब देने के लिए है प्रश्न:

एक सत्यापन त्रुटि एक गलती है। कल्पना कीजिए कि यदि आप सीमित त्रुटि प्रबंधन क्षमता वाले AJAX क्लाइंट से वेब सेवा का आह्वान करते हैं; आप चाहते हैं कि सेवा 5xx HTTP कोड वापस करे, न कि कुछ अप्रत्याशित प्रतिक्रिया के साथ 400 सफलता कोड।
नहीं एपीआई लगातार त्रुटि रिपोर्टिंग इंटरफेस प्रदान करना चाहिए। डब्ल्यूएसडीएल डिजाइन एपीआई डिजाइन है। क्लाइंट को दो अलग-अलग त्रुटि हैंडलर लागू करने के लिए मजबूर करना ग्राहक के जीवन को आसान नहीं बनाता है।
दोष डिजाइन आपके अनुरोध/प्रतिक्रिया मॉडल को दर्पण और सेवा के अबास्ट्रक्शन के लिए उचित जानकारी प्रदर्शित करना चाहिए। एक NullReference गलती डिजाइन न करें; एक XYZServiceRuntimeFault डिजाइन करें। यदि ग्राहक अक्सर अमान्य अनुरोध प्रदान करते हैं, तो उपयुक्त सबक्लास के साथ एक अवैधRequestFault डिज़ाइन करें ताकि ग्राहक जल्दी से पता लगा सकें कि अमान्य डेटा कहां है।

स्रोत

2010-06-21 18:17:11 gibbss

मुझे यह तय करने में कठिनाई हो रही है कि किसको जवाब देना है ... @ गिब्स पहले थे, @ रिचर्ड द्वारा संदर्भ अच्छे थे। मुझे लगता है कि आपने क्लाइंट को दो अलग-अलग त्रुटि हैंडलर लागू करने के लिए मजबूर किया "के साथ एक अच्छा बिंदु लाया। सिर्फ इसलिए कि कोई परिणाम ऑब्जेक्ट है जिसमें त्रुटि जानकारी हो सकती है इसका मतलब यह नहीं है कि SOAP दोष कभी नहीं होंगे। मैं इसे थोड़ा और अधिक कर दूंगा ... –

अच्छा जवाब। बस 400 कोड इंगित करना चाहते हैं कि एक बुरी अनुरोध प्रतिक्रिया है और 200 सफल प्रतिक्रिया है। – yogibear

@yogibear यदि वेब सर्वर त्रुटि फेंकता है तो यह 4xx होगा, यदि एप्लिकेशन त्रुटि को फेंकता है तो यह 5xx होगा, और सफलता 200 है। – lockstock

एक परिणाम वस्तु में केवल परिणाम होना चाहिए। यदि आपका परिणाम ऑब्जेक्ट किसी अन्य सिस्टम पर होने वाली त्रुटियों की एक सूची प्रदान कर रहा है तो यह एक उदाहरण है जब आप हो सकते हैं और "isError" ध्वज; अन्यथा आप नहीं कर सकते क्योंकि परिणाम या तो मान्य है या नहीं।

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

तो आपको परिणामों के लिए परिणाम ऑब्जेक्ट्स और SOAP दोषों का उपयोग किसी भी वैध परिणाम ऑब्जेक्ट को रोकता है; त्रुटियों, सत्यापन विफलताओं, चेतावनियों, बस दोषों, आदि तक सीमित नहीं है ..

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

SOAPFaults साथ मान्यता को संभालने के लिए/अपवाद अधिक तार्किक जब आप इसके बारे में सोचते है, और एक बार आप इसके बारे में सोचा है आम तौर पर आसान है। आपको सत्यापन गलती वर्ग को डिज़ाइन करने की आवश्यकता है ताकि इसमें अपमानजनक तत्वों की पहचान करने के लिए पर्याप्त जानकारी हो, जिसकी आवश्यकता मूल अनुरोध की आवश्यकता नहीं है। इस तरह आप प्रमाणीकरण त्रुटियों को अधिक सामान्य रूप से संभालना शुरू कर सकते हैं।
यदि परिणाम ऑब्जेक्ट में त्रुटियां हैं तो वे केवल परिणामों के डोमेन के भीतर हो सकती हैं; उदाहरण के लिए स्टॉक से बाहर उत्पाद क्योंकि वेयरहाउस में कोई व्यक्ति गणना नहीं कर सकता है सूची सूची के डोमेन के भीतर है।
महत्वपूर्ण त्रुटि और सत्यापन त्रुटि के बीच भेद करना बुद्धिमान नहीं है, यह मेरे दिमाग में वैध तुलना नहीं है क्योंकि गंभीरता स्तर का कोई असाइनमेंट बहुत ही व्यक्तिपरक है। उदाहरण के लिए फायरफाइटर को रसायनों के बारे में जानकारी प्रदान करने वाली प्रणाली में, महत्वपूर्ण रूप से इसका मतलब है कि आग पर ट्रक यूएन 12 9 8 & संयुक्त राष्ट्र 1436 ले रहा है और चेतावनी ग्राफिक लोड करने का प्रयास करते समय एक शून्य संदर्भ नहीं है।

त्रुटियों को डिजाइन करने के लिए उन्हें संक्षेप में पहचानने और तदनुसार संभालने की अनुमति देने के लिए डिज़ाइन करें। सुनिश्चित करें कि वे पर्याप्त जानकारी व्यक्त करते हैं। अनियंत्रित वर्गीकरण ऐसा कुछ है जो आपके पास पर्याप्त जानकारी प्राप्त होने पर अनावश्यक है क्योंकि दोष स्वयं को इंडेंटिफाइड होने की अनुमति देगा।
एसओएपीफ़ॉल्ट अपवादों में बदल गया है जो असफल होने का सबसे अच्छा तरीका है।
सर्वोत्तम अभ्यास, संदर्भ इत्यादि।

स्रोत

2010-06-22 14:30:01

बिंदु # 3 पर, मैं सत्यापन त्रुटियों को प्रदर्शित करना चाहता हूं (अमान्य में ई-मेल) और किसी अन्य प्रकार के अपवाद नहीं। मैं उन्हें समूहित करने के बारे में पूरी तरह से सहमत नहीं हूं। यही कारण है कि, हमारे पास .NET (IOException, ArgumentException, आदि) में इतनी सारी अपवाद कक्षाएं क्यों हैं। बेशक वे अभी भी अपवाद हैं और एक कस्टम तरीके से संभाले नहीं हैं, लेकिन वे समूहबद्ध हैं। –

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

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

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

स्रोत

2010-06-25 17:40:37 mdma

बढ़िया! आपके उत्तर के लिए धन्यवाद – iberck

नियम मैं सेवा डिजाइन में का पालन करें:

व्यापार स्तर प्रतिक्रिया (यहां तक कि व्यापार अपवाद) प्रतिक्रिया में साबुन दोष में

दोष वस्तुओं

तकनीकी/एकीकरण स्तर
सेवा उपभोक्ता इस बात पर भरोसा कर सकता है कि सभी प्रकार की व्यावसायिक प्रतिक्रिया प्रतिक्रिया वस्तुओं में आती है और इसे सेवा (बसि नेस) उपयोगकर्ता। साबुन दोष का उपयोग तब किया जाता है जब व्यापार प्रतिक्रिया वितरित नहीं की जा सकती है।

साबुन दोषों को निगरानी के माध्यम से एक समर्थन चेतावनी/कार्रवाई ट्रिगर करना चाहिए।

स्रोत

2017-02-14 15:25:05 KarelHusa

उत्तर

संबंधित मुद्दे