आरईएसटी एपीआई फ्रेमवर्क। अमान्य क्वेरीस्ट्रिंग पैरामीटर

Question

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

मैं उदाहरण देकर स्पष्ट करना होगा मैं एक विशिष्ट उदाहरण के साथ क्या मतलब है: कहो, मैं/api/संपर्क/endpoint पर एक API हैंडलर है, और हैंडलर जो ग्राहकों के साथ कुछ संपर्कों का चयन करने के लिए सक्षम बनाता है id नामक एक क्वेरी स्ट्रिंग फिल्टर, प्रदान करता है प्रदान की गई आईडी

तो, एक GET या DELETE अनुरोध /api/contacts/?id=2&id=4&id=lalalala हो सकता है।

स्पष्ट रूप से, id=lalalala के साथ संपर्क जैसी कोई चीज़ नहीं है। इस मामले में, सर्वर को किस तरह व्यवहार करना चाहिए?

• id=lalalala साथ अवैध संपर्क पर ध्यान न दें, और केवल वैध आईडी, 2 और एक त्रुटि कोड है कि इस त्रुटि को इंगित के साथ 4.

• जवाब पर संपर्कों को फ़िल्टर। यदि हां, तो कौन सा त्रुटि कोड प्रदान किया जाना चाहिए?

अग्रिम धन्यवाद।

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

Answer 1

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

हालांकि मैं निश्चित रूप से एक 4XX स्थिति कोड वापस कर दूंगा। आप ग्राहक को यह जानना चाहते हैं कि उन्होंने एक त्रुटि की है।

Answer 2

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

इस मामले मैं 400 - bad request संसाधन के रूप में के लिए जाना होगा में मिला था और सही ढंग से मैप किया (/api/contacts), लेकिन query string भाग के साथ एक समस्या थी। इसलिए 400 और 404 नहीं।

404 वापस लौटाएगा अगर किसी ने /api/contacts-all या कुछ गैर-मौजूदा संसाधन का अनुरोध किया है।

संपादित नीचे

टिप्पणी के आधार पर अपनी टिप्पणी से सहमत हूँ। आदर्श रूप से 400 अनुरोध के साथ एक समस्या है। इसके द्वारा जाकर, आप 422 Unprocessable Entity का उपयोग कर सकते हैं। कृपया नीचे दिए गए स्टैक ओवरफ्लो लिंक को देखें और यह एक ही चीज़ के बारे में बात करता है।

मुझे लगता है कि होता है कि दुनिया भर में डेवलपर्स तथ्य के कारण और अधिक आरामदायक एक 400 ऐसे तार्किक त्रुटियों के लिए 422 से देखकर हो कि बड़ा कंपनियों 400 और नहीं 422 का उपयोग कर रहे हैं।

संदर्भ: प्रतिक्रिया के लिए Http status codes और 400 for logical error vs malformed request