हम आरईएसटी अपवादों को संभालने के तरीके के बारे में एक सतत चर्चा के बीच में हैं।आरईएसटी अपवादों को कैसे संभालें?
रिस्पांस सामग्री के प्रकार: JSON
दो समाधान हमने:
तर्क:
काउंटर तर्क:
क्या आपका कहना है ??
एक JSON API के लिए मैंने हाल ही में विकसित किया है, मैं दोनों करता हूं। मैं हमेशा वैध JSON के साथ प्रतिक्रिया करता हूं (ठीक है, मान लीजिए कि मैं बिल्कुल जवाब देता हूं)। अगर मुझे एक अमान्य अनुरोध का पता चलता है, तो मैं स्थिति 400 का उपयोग करता हूं। अगर मुझे सर्वर त्रुटि का पता चलता है (जो मुझे विश्वास नहीं है अमान्य अनुरोध के कारण होता है), तो मैं 5xx स्थिति का उपयोग करता हूं। JSON ऑब्जेक्ट में एक विशेष कुंजी होती है जो केवल स्ट्रिंग मान के साथ त्रुटियों के लिए सेट होती है।
मुझे लगता है कि यह एक अच्छा समाधान है जो आरईएसटी सिद्धांतों का सम्मान करता है, और कई तरीकों से इसका उपयोग किया जा सकता है। वही समाधान किसी अन्य JSON एपीआई, जैसे याहू खोज द्वारा उपयोग किया जाता है। http://search.yahooapis.com/ImageSearchService/V1/imageSearch?appid=YahooDemo&output=json आज़माएं।
+1: HTTP के एक विश्वसनीय उपयोग के साथ आपको बिल्कुल HTTP प्रतिक्रिया कोड का लाभ उठाना होगा।प्रतिनिधित्व में अतिरिक्त जानकारी वापस की जा सकती है। –
मैंने अभी यह जवाब एसओ के "संबंधित" आइटमों में देखा है। और यद्यपि यह एक पुराना उत्तर है, यह स्पष्ट रूप से अभी भी दिख रहा है। मेरा मानना है कि HTTP स्टेटस कोड का उपयोग करने की तुलना में अच्छी त्रुटि हैंडलिंग के लिए * बहुत * अधिक है (हालांकि यह एक अच्छी शुरुआत है!)। गहराई से चर्चा के लिए http://soabits.blogspot.dk/2013/05/error-handling-considerations-and-best.html देखें। –
HTTP के लिए त्रुटि कोड का उपयोग करें। तो कुछ आंतरिक समस्या से किसी भी अपवाद के कारण 50 *। और 40 * खराब तर्क के लिए। जहां तक संभव हो अपने स्वयं के परिभाषित कोड का उपयोग करने से बचें। विचार "वर्दी" इंटरफ़ेस होना है।
सामान्य रूप से। संसाधन के जेसन प्रतिनिधित्व के साथ सफलता के लिए 204 सफलता के लिए सफलता के लिए 200 और यदि यह सफल ऑपरेशन उचित प्रतिक्रिया कोड वापस नहीं करता है। आप वैकल्पिक रूप से एक जेसन वापस करने का चयन कर सकते हैं। चीजों को सरल बनाने के लिए आपके पास सभी त्रुटि प्रतिक्रियाओं के लिए एक सामान्य प्रारूप (जेसन) हो सकता है।
http://en.wikipedia.org/wiki/REST आपके एपीआई चश्मा को फ्रीज करने से पहले अवश्य पढ़ना चाहिए।
"किसी भी सामग्री को भेजने के बिना सफलता के लिए 201"। 201 बनाया गया है, इसलिए इसका उपयोग तब किया जाना चाहिए जब "एक नया संसाधन [बनाया गया]", सामान्य सफलता के लिए नहीं। आप 204 के बारे में सोच रहे होंगे, "कोई सामग्री नहीं" –
ओह! सही। सुधारों के लिए धन्यवाद! –
मुझे आश्चर्य है कि प्रतिक्रिया कोड बहुत तकनीकी क्यों हैं। यदि आपको कोई सुधारात्मक कार्रवाई करनी है/तो आपको प्रतिक्रिया कोड (या जेसन के अंदर कोई अन्य त्रुटि कोड) पर निर्भर होना चाहिए, न कि उपयोगकर्ता पठनीय त्रुटि तार –
पर हम सभी प्रकार के ग्राहकों से निपटते हैं। तो हम यह नहीं मानना चाहते हैं कि ग्राहकों के साथ डेवलपर्स प्रतिक्रिया कोड को समझने के लिए पर्याप्त कुशल हैं। वह कुछ लोगों के विचार और मेरा भी था। अगर वे जेसन को देखते हैं तो वे त्रुटि को समझ सकते हैं। –
आरईएसटी के प्रमुख फायदों में से एक इंटरफेस की समानता है। तो जब आप कहते हैं कि हमारे पास एक आरईएसटी एपीआई है, तो ग्राहक स्वचालित रूप से संसाधनों की सूची का अनुमान लगाता है और पोस्ट डिलीट ऑपरेशन प्राप्त करता है और इसी तरह वह उस त्रुटि कोड के बारे में जानता है जिसे वह कल्पना कर सकता है। त्रुटि तार निश्चित रूप से आपके क्लाइंट (डेवलपर्स) के लिए डीबग करने के लिए उपयोगी होगा। लेकिन वे आपके एपीआई * के खिलाफ लिखने वाले कोड को कोड के आधार पर क्रियाएं लेना चाहिए और स्ट्रिंग नहीं करना चाहिए। –