REST API को यह इंगित करने के लिए 500 आंतरिक सर्वर त्रुटि वापस करनी चाहिए कि कोई क्वेरी किसी ऑब्जेक्ट का संदर्भ है जो मौजूद नहीं है?

Question

मैं एक REST एपीआई के साथ काम कर रहा हूं जो एक सर्वर पर रहता है जो IoT उपकरणों की भीड़ के लिए डेटा संभालता है।

मेरा काम एपीआई का उपयोग कर सर्वर को क्वेरी करने के लिए कहा गया है कि वह उपकरणों के बारे में विशिष्ट प्रदर्शन जानकारी एकत्र करे।

एक उदाहरण में, मैं उपलब्ध उपकरणों और उनके संबंधित पहचानकर्ताओं की एक सूची प्राप्त करता हूं, फिर बाद में उन पहचानकर्ताओं (GUID) का उपयोग करके अधिक विवरण के लिए सर्वर को क्वेरी करता हूं।

सर्वर 500 Internal Server Errorउन ID में से किसी एक पर क्वेरी के लिए वापस आ रहा है । मेरे आवेदन में, एक अपवाद फेंका गया है और मुझे त्रुटि के बारे में विवरण नहीं दिखता है। यदि मैं पोस्टमैन के साथ प्रतिक्रिया की अधिक बारीकी से जांच करता हूं, तो मैं देख सकता हूं कि सर्वर ने JSON को शरीर में वापस लौटा दिया है जिसमें शामिल हैं:

errorMessage: "This ID does not exist"।

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

REST API 500 Internal Server Errorको यह रिपोर्ट करने के लिए लौटना चाहिए कि कोई क्वेरी किसी ऑब्जेक्ट का संदर्भ है जो मौजूद नहीं है? मेरी सोच के लिए, HTTP प्रतिक्रिया कोड को एपीआई के आंतरिक यांत्रिकी के बजाय, आरईएसटी कॉल की स्थिति का कड़ाई से उल्लेख करना चाहिए। मैं 200 OKत्रुटि और विवरण के साथ प्रतिक्रिया के साथ उम्मीद करूंगा , जो कि एपीआई में प्रश्न में मालिकाना होगा।

---

यह मेरे लिए होता है कि REST कॉल कैसे संरचित है, इसके आधार पर अपेक्षा में संभावित अंतर है।

इन उदाहरणों पर विचार करें:

1. http://example.com/restapi/deviceinfo?id=123
2. http://example.com/restapi/device/123/info

पहले मामले में, डिवाइस आईडी को जीईटी चर के रूप में पारित किया जाता है। 404 या 500 इंगित करेगा कि पथ ( /restapi/deviceinfo) या तो नहीं मिला है या सर्वर त्रुटि के परिणामस्वरूप है।

दूसरे मामले में, डिवाइस आईडी URL का हिस्सा है। मुझे इसकी अधिक समझ होगी 404 Not Found, लेकिन फिर भी यह तर्क दे सकता है कि पथ के किन हिस्सों की व्याख्या चर बनाम समापन बिंदु के रूप में की जाती है।

Comments

क्या इस स्थिति का वर्णन आप एक सफलता या विफलता के रूप में कर रहे हैं?

— रॉबर्ट हार्वे

संबंधित (संभवतः एक डुप्लिकेट): क्या मुझे संसाधन नहीं मिलने पर 204 या 404 प्रतिसाद वापस करना चाहिए?

— gnat

@RobertHarvey मेरी उम्मीद थी कि एपीआई डिवाइस के बारे में कुछ जानकारी लौटाएगा। क्वेरी ही एक सफलता होनी चाहिए थी, लेकिन डिवाइस आईडी गायब होने पर अनुरोध स्तर पर विफलता का कारण नहीं होना चाहिए।

— ज्येल्टन

एक आईडी मेरे लिए 404 की तरह मौजूद नहीं है। 500 त्रुटियों का सबसे आम कारण प्रोग्रामर है जो होस्टिंग सर्वर को संभालने के लिए आंतरिक अपवाद को छोड़ देता है। कभी-कभी वास्तव में असाधारण मामले होते हैं जहां ऐसा होता है और कभी-कभी यह केवल आलसी प्रोग्रामिंग होता है। कहना मुश्किल है जो यहाँ चल रहा है।

— बेरिन लोरिट्श

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

— berry120

Answer 1

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

RFC 2616 के अनुसार , 404 स्थिति कोड की परिभाषा है:

10.4.5 404 नहीं मिला
सर्वर को अनुरोध-यूआरआई से मेल खाते हुए कुछ भी नहीं मिला है। कोई संकेत नहीं दिया जाता है कि क्या स्थिति अस्थायी या स्थायी है। 410 (चला गया) स्थिति कोड SHOULD का उपयोग किया जाना चाहिए यदि सर्वर को पता है, कुछ आंतरिक रूप से विन्यास योग्य तंत्र के माध्यम से, कि एक पुराना संसाधन स्थायी रूप से अनुपलब्ध है और इसका कोई अग्रेषण पता नहीं है। यह स्थिति कोड आमतौर पर उपयोग किया जाता है जब सर्वर यह प्रकट करने की इच्छा नहीं रखता कि अनुरोध को अस्वीकार क्यों किया गया है, या जब कोई अन्य प्रतिक्रिया लागू नहीं होती है।

Comments

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

— रॉबर्ट हार्वे

@ThomasOwens एक क्वेरी जो कोई परिणाम नहीं दे रही है वह 200 स्थिति और परिणामों की एक खाली सरणी लौटाएगी। एक 404 केवल तभी लौटाया जाएगा जब एक विशिष्ट ऑब्जेक्ट आईडी निर्दिष्ट किया जाएगा जो वास्तव में मौजूद नहीं है।

— सीन बर्टन

@ThomasOwens: कॉल करने वाले के विचार से, समापन बिंदु नहीं है /questions, यह है /questions/368213। वह समापन बिंदु आपके परिदृश्य में मौजूद नहीं है। इसे इस तरह से सोचें: यदि आप / foo / bar पर GET करते हैं और कोई बार नहीं है, तो प्रतिक्रिया अलग-अलग होनी चाहिए यदि / foo मौजूद है या नहीं?

— ब्रायन ओकले

ठीक है, यह एक सर्वर त्रुटि नहीं है इसलिए हम 5xx नहीं भेजते हैं। यह एक क्लाइंट त्रुटि है - क्लाइंट के पास कुछ नहीं है, इसलिए हम 4xx भेजते हैं, विशेष रूप से 404।

— bdsl

@ThomasOwens: How do you differentiate between a 404 meaning "the query returned no results" and a 404 meaning "the endpoint does not exist"?- 400 खराब अनुरोध।

— रॉबर्ट हार्वे

Answer 2

मैं आपके उदाहरणों का उपयोग करूंगा।

http://example.com/restapi/deviceinfo?id=123

यदि समापन बिंदु एक json सरणी देता है , तो इसके लिए सबसे अच्छा विकल्प 200 OKखाली सरणी के साथ है यदि कोई परिणाम नहीं मिला।

यदि समापन बिंदु को एक परिणाम वापस करने के लिए डिज़ाइन किया गया है , तो मेरी पसंद होगी 404 NOT FOUND, क्योंकि, मेरे लिए, इस तरह के समापन बिंदु के लिए सही सिंटैक्स है http://example.com/restapi/deviceinfo/123:। मैं आमतौर पर रिक्वेस्ट परम का उपयोग केवल फ़िल्टरिंग के लिए करता हूं और जब मेरा एंडपॉइंट एक सरणी देता है।

http://example.com/restapi/device/123/info

मुझे लगता है कि इस सवाल का जवाब यहां पहले ही दिया जा चुका था । POST या GET, बेहतर विकल्प लगता है 404 NOT FOUNDक्योंकि संसाधन 123नहीं मिला।

दोनों मामलों में मैं अनुरोध पूरा नहीं होने का कारण स्पष्ट करने की आवश्यकता नहीं देख सकता। अनुरोध जानकारी और HTTP कोड पहले ही बता देता है कि क्यों।

Comments

आप एक बिना आईडी और खराब URL के बीच अंतर कैसे करते हैं?

— रॉबर्ट हार्वे

@luizfzs, आप यह भी कर सकते हैं, मैं उस पर एक समस्या नहीं देख सकता। मेरे द्वारा विकसित किए गए कुछ एपीआई में, मैं प्रतिक्रिया के बिना किसी निकाय के सफल PUT या DELETE ( जैसा कि यहां बताया गया है ) में 204 का उपयोग करना पसंद करता हूं ।

— धेरिक

आपको उस स्तर पर एक बिना आईडी और खराब URL के बीच अंतर क्यों करना चाहिए ? किसी भी तरह से आप अभी भी एक वैध अनुरोध कर रहे हैं, जहां तक ​​HTTP का संबंध है। सर्वर बस ... अच्छी तरह से ... आप जिस संसाधन को संबोधित कर रहे हैं वह नहीं मिल सकता है । एक खराब URL एक विकृत अनुरोध नहीं है; यह गलत काम के लिए एक अच्छी तरह से गठित अनुरोध है ।

— cHao

@cHao क्योंकि एक डेवलपर के रूप में, मैं जानना चाहता हूं कि क्या मेरा ऐप विफल हो रहा है क्योंकि आइटम मौजूद नहीं है, या अगर मैंने गलती से अपने ऐप को app.company.cxm / test / बजाय app.company.cxm / tst / के बजाय इंगित किया है

— पैट्रिक एम

@PatrickM: एक डेवलपर के रूप में, आपको पता होना चाहिए कि त्रुटि प्रतिक्रियाओं में एक संदेश निकाय भी हो सकता है। यदि आप वास्तव में यह चाहते हैं तो व्याख्यात्मक त्रुटि जानकारी जाती है। शब्दार्थ को केवल इसलिए न तोड़ें क्योंकि आप मोटी उंगलियों के बारे में पागल हैं। HTTP स्तर पर, इससे कोई फर्क नहीं पड़ता कि आपने गड़बड़ की है /itms/1234या /items/12234।

— काहो

Answer 3

HTTP 404 सही है, क्योंकि सर्वर समझता है कि ग्राहक किस संसाधन के लिए पूछ रहा है, लेकिन उसके पास वह संसाधन नहीं है।

तथ्य यह है कि आप एक "आराम एपीआई" के साथ काम कर रहे हैं कुंजी है। एपीआई को ऐसा व्यवहार करना चाहिए जैसे वह किसी कार्य को अंजाम दे रहा हो, कोई स्टेटिक ट्रांसफर ट्रांसफर कर रहा हो। (निश्चित रूप से, "REST" शब्द का व्यापक अर्थ आया है, लेकिन आप अभी भी इसके शाब्दिक अर्थ का उपयोग यहां अच्छे प्रभाव के लिए कर सकते हैं।) क्लाइंट ने URL द्वारा वर्णित संसाधन की स्थिति के लिए कहा है http://example.com/restapi/device/123/info। एक querystring ( /deviceinfo?id=123) स्थिति को नहीं बदलेगा। सर्वर को पता है कि आप डिवाइस 123 की स्थिति को स्थानांतरित करने के लिए कह रहे हैं, लेकिन यह ज्ञात संसाधन के रूप में पहचान नहीं करता है। इसलिए HTTP 404।

यहाँ चर्चा की गई अन्य संभावित प्रतिक्रियाओं के विशिष्ट अर्थ भी हैं:

• HTTP 200- हमें आपके लिए राज्य मिला; यह प्रतिक्रिया शरीर में है।
• HTTP 204- हमें आपके लिए राज्य मिला; यह खाली है।
• HTTP 400- हम यह नहीं बता सकते कि आप किस संसाधन के बारे में पूछ रहे हैं। अपना URL ठीक करें।
• HTTP 500- हमने खराबी की। तुम्हारी गलती नहीं।

RFC 2616 Sec देखें । १० उपयुक्त।

Comments

मैं आपकी इस बात से सहमत हूं। यदि सर्वर 404 लौटा रहा था, तो यह समझ में आता है कि यह क्या कर रहा है (500)। धन्यवाद।

— ज्येल्टन

Answer 4

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

अगर कोई क्वेरी कोई परिणाम नहीं देती है, तो किसी भी तरह का अधिवेशन करने पर मैं अनिश्चित हूं। मैंने दोनों को देखा है जो आप का वर्णन करते हैं (एक शरीर के साथ एक 200 जिसमें एक संदेश होता है) और साथ ही एक 404 यह दर्शाता है कि परिणाम नहीं मिला। 200 शायद सबसे अधिक समझ में आता है - अनुरोध सफलतापूर्वक पूरा हो गया और ग्राहक के अनुरोध के साथ या सर्वर द्वारा अनुरोध को संसाधित करने के दौरान कोई समस्या नहीं थी। एक ग्राहक को संदेश दे सकता है।

---

मैं आपके दोनों उदाहरणों ( http://example.com/restapi/deviceinfo?id=123और http://example.com/restapi/device/123/info) को एक ही मानूंगा - 123एक पैरामीटर है। दोनों मामले आईडी 123 के साथ डिवाइस के लिए डिवाइस की जानकारी प्राप्त करने के अनुरोध को संरचित करने के विभिन्न तरीके हैं।

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

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

यदि सभी पैरामीटर मान्य थे, तो मैं अनुरोध को संसाधित करना शुरू कर दूंगा। यदि सिस्टम या कोई निर्भरता (एक डेटाबेस, एक तृतीय-पक्ष सेवा, एक अन्य आंतरिक सेवा) अनुपलब्ध है, तो मैं एक 5xx कोड लौटाऊंगा - 503 विशिष्ट होगा, लेकिन एक 500 भी स्वीकार्य होगा। किसी भी मामले में, मैं अतिरिक्त विवरण के साथ एक निकाय लौटाऊंगा। इस बात पर विचार करें कि यदि कोई बाहरी निर्भरता 408 रिक्वेस्ट टाइमआउट की रिपोर्ट करती है, तो मैं उसे खाऊंगा और अपने क्लाइंट को 500 लौटा दूंगा, जिससे एक क्लाइंट को केवल 408 प्राप्त करने की अनुमति मिलती है, यदि मेरे सिस्टम से अनुरोध समय पर हो। यदि सिस्टम अनुरोध को पूरा करने में सक्षम है, तो मैं एक 200 और उपयुक्त निकाय लौटाऊंगा।

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

केवल एक बार जब 404 लौटाया जाएगा, अगर सर्वर में एक /deviceinfoसमापन बिंदु या एक /device/:id/infoसमापन बिंदु नहीं था ।

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

Comments

@ रोबर्टहेरवे हाँ। कोई त्रुटि नहीं थी। सिर्फ इसलिए कि सर्वर ने GUID उत्पन्न किया और ग्राहक को भेजा इसका मतलब यह नहीं है कि किसी अन्य ऑपरेशन ने इसे हटा दिया। अनुरोध / प्रतिक्रिया सफल रही। अनुरोध द्वारा दर्शाई गई कमांड या क्वेरी डेटा वापस नहीं करती है। मेरे लिए, यह एक विफलता नहीं है। यह एक अपवाद हो सकता है, लेकिन मैं आश्वस्त नहीं हूं कि यह 5xx के योग्य है।

— थॉमस ओवेन्स

अगर मैं इस एपीआई को डिजाइन कर रहा था जिसे मैं क्वेरी कर रहा हूं, तो मुझे 200 ऐसे बॉडी के साथ वापस करना होगा जिसमें कुछ प्रभाव होता है device: 123; status: not found;। तब मुझे पता है कि क्वेरी काम की है, और एपीआई मुझे उपयोगी जानकारी बता रहा है।

— जेल्टन

500 पृष्ठों की बहुत सी वेबसाइट्स के शब्दों द्वारा @Brfl का बैकअप लिया जाता है (हालाँकि "सिद्ध नहीं"), आमतौर पर ऐसा कुछ होता है जैसे "हमने गलती की, और जाँच करेंगे"। मेरे दिमाग में ठीक से काम करने वाला सर्वर कभी भी 500 नहीं भेजता है, सिवाय ब्रह्मांडीय किरणों के मामले में।

— मब्रिग

Http में 'एंडपॉइंट' की कोई अवधारणा नहीं है, एक चर और बाकी URL के बीच कोई प्रासंगिक अंतर नहीं है, और इसलिए न तो आराम है। आपके पास एक राउटिंग सिस्टम हो सकता है जो रेगेक्स पर मेल खाता है और हजारों यूआरएल को एक कंट्रोलर फंक्शन में रूट करता है, लेकिन यह एक इम्प्लीमेंटेशन डिटेल है, एपीआई का फंडामेंटल हिस्सा नहीं है। एक प्राप्त पर 200 की प्रतिक्रिया केवल उस मामले के लिए है जब अनुरोधित संसाधन को पुनर्प्राप्त किया जा रहा है। इस मामले में ग्राहक एक ऐसे संसाधन का प्रतिनिधित्व चाहता है जो मौजूद नहीं है, इसलिए 404 सही प्रतिक्रिया है।

— bdsl

एक ठीक प्रकार से कार्य करने वाला सिस्टम कभी भी 500 प्रतिसाद नहीं भेजता है। एक ठीक से कार्य करने वाला सर्वर 500 भेज सकता है क्योंकि यदि वह एक बड़ी प्रणाली का हिस्सा है और उसने उस बड़ी प्रणाली में आंतरिक त्रुटि का पता लगाया है, जैसे डेटाबेस डाउन है, या वेब सेवा पर निर्भर अन्य बकवास परिणाम दे रहा है।

— bdsl

Answer 5

500-श्रृंखला HTTP त्रुटि सर्वर की खराबी को इंगित करता है। इसके अलावा 501 Not Implementedऔर 505 HTTP Version Not Supported, इन त्रुटि कोडों का उपयोग करने का तात्पर्य है कि बाद के समय में अनुरोध को पुनः प्राप्त करना सफल हो सकता है (हालांकि केवल 503 Service Unavailableस्पष्ट रूप से बताता है)। आदर्श रूप से, एक सर्वर को कभी भी इन कोडों में से एक का उत्पादन नहीं करना चाहिए, हालांकि बग-मुक्त सॉफ़्टवेयर लिखने में असमर्थता और अनंत संसाधनों वाले सर्वर का प्रावधान करने का मतलब है कि आपको समय-समय पर उनकी आवश्यकता होगी।

"ऑब्जेक्ट मौजूद नहीं है" परिणाम के लिए, आपको संभवतः 404 Not Found( या जब नाम से किसी ऑब्जेक्ट के लिए अनुरोध है), या 200 Successखाली परिणाम निकाय के साथ (जब विशेषताओं द्वारा किसी ऑब्जेक्ट की खोज करना हो) वापस करना चाहिए । 204 No Contentलुभावना लगता है, लेकिन मैं इसे केवल उन स्थितियों के लिए उपयोग करूंगा जहां एक प्रतिक्रिया शरीर की कमी अपेक्षित परिणाम है।

Answer 6

जब मैं इनमें से कोई भी कॉल करता हूं, तो आपके API के क्लाइंट के रूप में:

1. http://example.com/restapi/deviceinfo?id=123
2. http://example.com/restapi/device/123/info

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

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

इसका अर्थ है, एक एपीआई उपभोक्ता के रूप में, कि मैं कुछ प्रकार के चेक-रेस्ट-कॉल फ़ंक्शन का उपयोग कर सकता हूं जो एक प्रतिक्रिया प्राप्त करता है या एक अपवाद फेंकता है। एक दम बढ़िया; मेरा सामान्य तर्क स्ट्रेट लाइन कोड हो सकता है, और मैं अपनी त्रुटि-हैंडलिंग उसी तरह व्यवस्थित कर सकता हूं जैसे मैं स्थानीय कोड में करता हूं। अप्रत्याशित 404 "बिना कोई संसाधन पाए" अपवाद के रूप में प्रकट होंगे, मेरे बिना कुछ भी नहीं होने देंगे, "लापता विशेषता" त्रुटियों के रूप में नहीं जब मैं बाद में प्रसंस्करण कर रहा हूं { errorMessage: "Device 123 not found" }जैसे कि यह एक DeviceInfoवस्तु थी।

यदि आप कारण है कि समापन बिंदु पाया http://example.com/restapi/deviceinfo जाता है, और यह केवल id=123वह नहीं है, और इसलिए शरीर में एक त्रुटि संदेश के साथ 200 लौटाते हैं, तो आप बिल्कुल उसी तरह की इंटरफ़ेस समस्याएं पैदा कर रहे हैं जैसे कि सी फ़ंक्शन जो कि या तो वापस आ सकते हैं सही परिणाम या त्रुटि कोड, या विधियाँ जो मनमाने ढंग से लौटकर समस्याओं का संकेत देती हैंnull। आपके इंटरफ़ेस के उपयोगकर्ता के रूप में यह बहुत अच्छा है कि नियमित रिटर्न से "अलग" चैनल के माध्यम से त्रुटियों का संकेत मिलता है। यह यहाँ भी लागू होता है, भले ही HTTP 200, 404, और 500 प्रतिक्रियाएँ निम्न स्तर के दृष्टिकोण से एक ही चैनल हैं। वे मानकीकृत और आसानी से बता सकते हैं, इसलिए मेरे बाकी ग्राहक ढांचे को आसानी से उन स्थितियों पर स्विच कर सकते हैं जो उन्हें मेरी भाषा में उचित संरचनाओं में बदल सकते हैं; JSON परत के साथ एक ही काम करने के लिए (जहां आप हमेशा 200 कहते हैं और मुझे या तो एक DeviceInfoया एक त्रुटि संदेश देते हैं) मुझे आपके द्वारा उपयोग किए जाने वाले JSON स्कीमा के कुछ ज्ञान को एम्बेड करने की आवश्यकता है।

इसलिए केवल 200 का उपयोग करें जब आप अपेक्षित प्रकार का वैध मान लौटा सकते हैं (यही कारण है कि http://example.com/restapi/search-devices?colour=blueअगर कोई नीली डिवाइस नहीं है, तो खाली सरणी के साथ 200 वापस कर सकते हैं; एक खाली सरणी एक वैध सरणी है, और अनुरोध का एक समझदार उत्तर है "I सभी नीले उपकरणों का विवरण चाहेंगे ")। यदि आप नहीं कर सकते हैं, तो सबसे उपयुक्त गैर-200 स्थिति कोड का उपयोग करें। भले ही "डिवाइस 123 मौजूद नहीं है" "मुझे डिवाइस 123 का विवरण देने के लिए" सही प्रतिक्रिया है, और सर्वर के लिए कोई त्रुटि नहीं है , यह क्लाइंट की उम्मीद के लिए एक अपवाद है कि उन्हें वापस मिल जाएगा DeviceInfoऔर चाहिए एक सामान्य के रूप में संवाद नहीं किया जाना चाहिए "यहां वही है जो आपने" प्रतिक्रिया के लिए पूछा था।

Comments

दुर्भाग्य से मैं भी इस एपीआई का ग्राहक हूं और इसे बदल नहीं सकता। हालांकि यह कैसे काम करना चाहिए , इसका एक बड़ा सारांश है ।

— जेल्टन

Answer 7

आप नहीं मिला 404 से अंतर करने के लिए त्रुटि 422 Unprocessable Entity का उपयोग कर सकते हैं । 422 का मतलब है कि सर्वर अनुरोध को समझता है लेकिन यह उचित प्रतिक्रिया नहीं दे सकता है। मैं इसी तरह की स्थितियों पर इस कोड का उपयोग कर रहा हूं।

Comments

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

— रॉबर्ट हार्वे

धन्यवाद, बहुत उपयोगी! मुझे इस विषय को और गहरा करना होगा!

— FiNeX

Answer 8

500 त्रुटि आमतौर पर इंगित करता है कि अनुरोध एक सर्वर साइड प्रोग्राम दुर्घटनाग्रस्त हो गया; उद्यम के वातावरण में इन त्रुटियों को एक अंडे के रूप में माना जाता है और इससे बचा जा रहा है।

त्रुटि 4xx को प्रोग्रामर को संकेत देना चाहिए कि एपीआई एंडपॉइंट (संसाधन) मौजूद नहीं है। नतीजतन, एक बार उपयुक्त समापन बिंदु तक पहुंचने के बाद, उस बिंदु से किसी भी त्रुटि से निपटने के लिए एपीआई के प्रोग्रामर की जिम्मेदारी होती है, जिसे 200 की प्रतिक्रिया के त्रुटि संदेश के साथ सुशोभित किया जाना चाहिए।

Comments

तो आप कह रहे हैं "आप 500 का उपयोग नहीं करते क्योंकि आप सर्वर को क्रैश नहीं कर रहे हैं?"

— रॉबर्ट हार्वे

Answer 9

हालाँकि w3 नोट जो 404 का उपयोग किया जाता है जब कोई अन्य प्रतिक्रिया लागू नहीं होती है , तो क्या यह 204 (कोई सामग्री नहीं) प्रतिक्रिया के लिए अच्छा होगा? अनुरोध एक प्रसंस्करण दृष्टिकोण से मान्य था और सर्वर ने अनुरोध को संसाधित किया और इसका परिणाम है। यह एक सफलता है, जो 2xx प्रतिक्रियाओं की ओर झुकती है। इस विशेष अनुरोध के लिए कोई सामग्री नहीं थी इसलिए 204 उपयोगकर्ता को बताता है कि उनकी क्वेरी के साथ कुछ भी गलत नहीं था लेकिन वहां कुछ भी नहीं है।

आप एक कमजोर मामला भी बना सकते हैं कि 409 (संघर्ष) एक उचित प्रतिक्रिया है। हालांकि, 409 को अक्सर एक POST के लिए उपयोग किया जाता है, यह कहता है

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

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

Comments

नहीं, एक अनुरोध पर 204 प्रतिक्रिया केवल तभी समझ में आएगी जब अनुरोधित संसाधन मिल गया है, और इसका प्रतिनिधित्व बिल्कुल शून्य वर्ण लंबा है।

— bdsl

Answer 10

अन्य उत्तर इसे कवर करते हैं, लेकिन मैं सिर्फ यह बताना चाहता था कि 500 ​​सीरीज़ की त्रुटि का अर्थ है "मैंने गड़बड़ की।" इस स्थिति में, "I" का अर्थ एपीआई है, इसलिए एक अनहेल्ड सर्वर त्रुटि या समान। 400-सीरीज़ की त्रुटि का अर्थ है "आपने गड़बड़ कर दी" - एपीआई के कॉलर ने कुछ गलत भेजा।

Answer 11

यदि आप पुस्तक द्वारा जाना चाहते हैं, तो अन्य उपयोगकर्ताओं ने मान्य उत्तर दिए हैं।

हालाँकि मैं आपको सुझाव दूंगा कि आप रिस्तेफुलनेस में बहुत अधिक पढ़ रहे हैं और इसके संबंध में पूरी तरह से कोषेर हैं।

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

एक अलग दृष्टिकोण है: पूरी तरह से उत्साह को बढ़ाएं, और इसे संचार प्रोटोकॉल के रूप में उपयोग करें और कुछ नहीं। इसका मतलब यह है कि केवल प्रतिक्रियाओं को वापस करने की आवश्यकता है "HTTP 200 ठीक" और "HTTP 500 आंतरिक सर्वर त्रुटि" क्योंकि जहां तक ​​संचार प्रोटोकॉल का संबंध है, संवाद करने के किसी भी प्रयास में केवल दो परिणाम हो सकते हैं: या तो अनुरोध सफलतापूर्वक किया गया था सर्वर पर दिया गया है, या नहीं।

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

तो, नीचे की रेखा है, मैं "HTTP 200 ओके" वापस भेजने की सलाह दूंगा और प्रतिक्रिया पेलोड के भीतर ("HTTP सामग्री में" प्रतिक्रिया सामग्री निकाय) एक एप्लिकेशन-विशिष्ट त्रुटि कोड है जो कहता है "आईडी नहीं मिला" या जो भी हो।

Comments

नीचे की ओर देखते हुए, मुझे लगता है कि मैंने कुछ लोगों की भावनाओं को आहत किया होगा। या शायद उनके शरीर का कोई और हिस्सा। C -: =

— माइक नकिस

उन्हें वास्तव में इसे पढ़ना चाहिए: blogs.dropbox.com/developers/2015/04/…

— माइक

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

— cHao

@ CHao तो, मुझे लगता है कि "ड्रॉपबॉक्स वर्तमान में लगभग 10 अलग-अलग स्टेटस कोड (सफलता के लिए 8 और 2) का उपयोग करता है, लेकिन हम उस संख्या को एपीआई के भविष्य के संस्करण में कम करने की योजना बना रहे हैं" आप।

— माइक नाकिस

इसका मतलब यह नहीं था कि आप इससे क्या प्राप्त कर रहे हैं। यदि वे जानते हैं कि वे क्या कर रहे हैं, तो सबसे चरम पर, वे इसे एक सफलता और चार त्रुटि कोड (400, 401, 404, और 500) तक कम कर देंगे, क्योंकि वे स्पष्ट रूप से सम्मेलनों की परवाह करते हैं।

— cHao