अमान्य डेटा के लिए REST प्रतिक्रिया कोड

Question

निम्नलिखित परिदृश्यों के मामले में ग्राहक को क्या प्रतिक्रिया कोड दिया जाना चाहिए?

1. उपयोगकर्ता द्वारा गलत ईमेल प्रारूप की तरह पंजीकरण करते समय अमान्य डेटा पारित किया गया
2. उपयोगकर्ता नाम / ईमेल पहले से मौजूद है

मैंने 403 को चुना। मैंने यह भी पाया कि मुझे लगता है कि इसका इस्तेमाल किया जा सकता है।

विकिपीडिया:

412 पूर्वधारणा विफल: सर्वर उन पूर्व शर्तों में से एक को पूरा नहीं करता है जो अनुरोधकर्ता ने अनुरोध पर रखी थी

यदि मुझे 403 के अलावा अन्य उपयोग करना चाहिए तो कोड सुझाएं।

Comments

संभावित डुप्लिकेट: stackoverflow.com/questions/3050518/…

— Genjo

मैं इस मुद्दे को भी हल कर रहा हूं। अध्याय 7. JAX-RS कल्पना (2017) का अमान्यकरण विशेष रूप से बाधा उल्लंघन के लिए स्थिति कोड सलाह प्रदान करता है। download.oracle.com/otn-pub/jcp/jaxrs-2_1-final-spec/…

— burntsugar

Answer 1

400 दोनों मामलों में सबसे अच्छा विकल्प है। यदि आप त्रुटि को और स्पष्ट करना चाहते हैं, तो आप कारण वाक्यांश को बदल सकते हैं या त्रुटि को समझाने के लिए एक निकाय शामिल कर सकते हैं।

412 - पिछली बार संशोधित तिथि और ETags का उपयोग करते समय पूर्व-शर्त सशर्त अनुरोधों के लिए उपयोग की जाती है।

४०३ - निषिद्ध का उपयोग तब किया जाता है जब सर्वर किसी संसाधन तक पहुँच को रोकना चाहता है।

केवल दूसरी पसंद जो संभव है वह है 422 - अनुत्पादक इकाई।

Comments

हालांकि इस संदर्भ में इसका अक्सर उपयोग किया जाता है, 403 नियंत्रणों तक सीमित नहीं है, क्योंकि rfc2616-10.4.4 कहते हैं: "सर्वर अनुरोध को समझ गया, लेकिन इसे पूरा करने से इनकार कर रहा है। [...] यदि सर्वर बनाना चाहता है। सार्वजनिक क्यों अनुरोध पूरा नहीं किया गया है, यह इकाई में इनकार के कारण का वर्णन करता है। " कारण अमान्य डेटा हो सकता है। हालांकि, 422 यहां अधिक लागू है।

— यानिक लोइसो

पाठकीय आलोचना में मत फंसिए। उदाहरण के लिए देखें trac.tools.ietf.org/wg/httpbis/trac/ticket/294 जो स्पष्ट करने का प्रयास करता है कि 403 है और हमेशा प्राधिकरण के बारे में था।

— फुकुन्चू

@ फुमानचू अच्छा कैच। एक परिवर्तन अनुरोध का लिंक जो केवल 7 घंटे पुराना है :-)

— डारेल मिलर

@fumanchu इसका मतलब है कि उपयोगकर्ता द्वारा अनुरोधित संसाधन तक पहुँचने की अनुमति नहीं होने की स्थिति में 403 को लौटाया जाना चाहिए। लेकिन मुझे लगता है कि 401 अनधिकृत संसाधन तक पहुँचने के लिए अधिक उपयुक्त है जिस पर उपयोगकर्ता की अनुमति नहीं है।

— अमित पटेल

401 अनधिकृत एक वेब ब्राउज़र को उपयोगकर्ता को मानक HTTP उपयोगकर्ता नाम / पासवर्ड संकेत दिखाने के लिए संकेत देगा। यदि आप अपनी सेवा के लिए उस तरह के प्रमाणीकरण का उपयोग नहीं कर रहे हैं, या यदि उपयोगकर्ता के पास पहले से ही HTTP प्रमाणीकरण है, तो 401 उपयुक्त नहीं है।

— ग्रेग बॉल

Answer 2

मैं 422 की सिफारिश करूंगा। यह मुख्य HTTP युक्ति का हिस्सा नहीं है, लेकिन इसे एक सार्वजनिक मानक (WebDAV) द्वारा परिभाषित किया गया है और इसे किसी अन्य 4xx स्थिति कोड के समान ही ब्राउज़र द्वारा व्यवहार किया जाना चाहिए।

से आरएफसी 4918 :

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

Comments

ध्यान दें कि उद्धृत पाठ में कहा गया है कि 422 तब लागू होता है जब अनुरोध इकाई वाक्य-रचना अच्छी तरह से बनती है, लेकिन शब्दार्थ गलत है। यदि अनुरोध इकाई को गारबेज किया गया है, तो 400 उपयुक्त प्रतिक्रिया है।

— मैटी के

Answer 3

यदि अनुरोध सही ढंग से पार्स नहीं किया जा सकता है (अनुरोध इकाई / निकाय सहित) उपयुक्त प्रतिक्रिया 400 खराब अनुरोध [ 1 ] है।

RFC 4918 में कहा गया है कि 422 अनप्रोसेबल एंटिटी तब लागू होती है जब रिक्वेस्ट एंटिटी सिंटैक्टली अच्छी तरह से बनाई गई हो, लेकिन शब्दार्थ गलत है। इसलिए यदि अनुरोध इकाई को खराब कर दिया गया है (जैसे खराब ईमेल प्रारूप) 400 का उपयोग करें; लेकिन अगर यह सिर्फ मतलब नहीं है (जैसे @example.com) 422 का उपयोग करें।

यदि समस्या यह है कि, जैसा कि प्रश्न में कहा गया है, उपयोगकर्ता नाम / ईमेल पहले से मौजूद है, तो आप संघर्ष के विवरण के साथ 409 संघर्ष [ 2 ] का उपयोग कर सकते हैं , और इसे कैसे ठीक करें (इस मामले में, "इस बारे में एक संकेत विभिन्न उपयोगकर्ता नाम / ईमेल ")। हालाँकि लिखित रूप में, 403 निषिद्ध [ 3 ] का उपयोग इस मामले में भी किया जा सकता है, HTTP प्राधिकरण के बारे में तर्क।

412 पूर्वधारणा विफल [ 4 ] का उपयोग तब किया जाता है जब एक पूर्व-भुगतान अनुरोध हेडर (जैसे If-Match) जो क्लाइंट द्वारा आपूर्ति किया गया था, झूठे का मूल्यांकन करता है। अर्थात्, क्लाइंट ने कुछ अनुरोध किया और पूर्व शर्त को पूरा किया, यह अच्छी तरह से जानते हुए कि उन पूर्व शर्त विफल हो सकती हैं। 412 को कभी भी नीले रंग के ग्राहक पर नहीं उछाला जाना चाहिए, और प्रति अनुरोध अनुरोध इकाई से संबंधित नहीं होना चाहिए ।

Comments

मुझे अद्यतन HTTP / 1.1 RFCs: 400 खराब अनुरोध, 409 संघर्ष, 403 निषिद्ध आदि को ध्यान में रखना चाहिए । 412 पूर्वधारणा

— Matty K

Answer 4

यह उन 418 I'm a teapotअनुरोधों पर लौटने से इनकार कर रहा है जो स्पष्ट रूप से तैयार किए गए या दुर्भावनापूर्ण हैं और "नहीं हो सकते हैं", जैसे कि सीएसआरएफ चेक या लापता अनुरोध गुणों को विफल करना।

२.३.२ ४१ a मैं एक चायदानी हूँ

एक चायदानी के साथ कॉफी काढ़ा करने का कोई भी प्रयास त्रुटि कोड "418 मैं चायदानी" के परिणामस्वरूप होना चाहिए। परिणामी निकाय निकाय छोटा और मोटा होना चाहिए।

इसे यथोचित रूप से गंभीर बनाए रखने के लिए, मैं मज़ेदार त्रुटि कोड के उपयोग को RESTful समापन बिंदुओं तक सीमित करता हूं जो सीधे उपयोगकर्ता के सामने नहीं आते हैं।

Comments

इसे ऐसे लागू करें कि आपका एपीआई 418 I'm a teapotआपके बॉस से आने वाले सभी अनुरोधों के लिए वापस आ जाए :)

— vikarjramun

@vikarjramun i buildve ने एक डमी रेस्ट का निर्माण किया और प्रूडेंटिव को एक ऑफ़लाइन बनाया। (प्रीलेयरेज़) अब हमारे छात्र वैध डेटा-अनुरोध बनाने की कोशिश कर रहे हैं, लेकिन यह सभी चायदानी है। मैं "बॉस" हूँ - लेकिन यह भी काम कर रहा है।

— लेंगलबॉय

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

— गब्बर

@ बर्बटन को मानव द्वारा हस्तक्षेप की आवश्यकता होती है, हालांकि। नेटवर्क पर, कॉफी बनाने के लिए आपको निश्चित रूप से कॉफी-सक्षम डिवाइस की आवश्यकता होती है। बेशक, एक कॉफी और चायदानी को 418 के साथ प्रतिक्रिया नहीं देनी चाहिए।

— जैस्पर