400 बनाम 422 डेटा के POST की प्रतिक्रिया

Question

मैं यह पता लगाने की कोशिश कर रहा हूं कि "REST-like" API के साथ विभिन्न परिदृश्यों पर लौटने के लिए सही स्थिति कोड क्या है जिस पर मैं काम कर रहा हूं। मान लीजिए कि मेरे पास एक अंतिम बिंदु है जो JSON प्रारूप में POST'ing खरीदारी की अनुमति देता है। यह इस तरह दिख रहा है:

{
    "account_number": 45645511,
    "upc": "00490000486",
    "price": 1.00,
    "tax": 0.08
}

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

Comments

REST

— अनिरुद्ध रामनाथन

Answer 1

400 बुरा अनुरोध अब आपके उपयोग के मामले के लिए सबसे अच्छा HTTP / 1.1 स्थिति कोड प्रतीत होगा।

आपके प्रश्न के समय (और मेरा मूल उत्तर), RFC 7231 कोई बात नहीं थी; जिस बिंदु पर मैंने आपत्ति जताई 400 Bad Requestक्योंकि RFC 2616 ने कहा (जोर देने के साथ):

अनुरोध सर्वर द्वारा विकृत सिंटैक्स के कारण समझा नहीं जा सका ।

और आप जिस अनुरोध का वर्णन करते हैं वह वाक्यविन्यास रूप से मान्य JSON है, जो कि वाक्यात्मक रूप से मान्य HTTP में संलग्न है, और इस प्रकार सर्वर में अनुरोध के वाक्य विन्यास के साथ कोई समस्या नहीं है ।

हालाँकि जैसा कि टिप्पणियों में ली सेफेराइट ने कहा है , RFC 7231, जो RFC 2616 का अनुसरण करता है, उस प्रतिबंध को शामिल नहीं करता है :

400 (खराब अनुरोध) स्थिति कोड इंगित करता है कि सर्वर किसी क्लाइंट त्रुटि के कारण होने वाली चीज़ के कारण अनुरोध को संसाधित नहीं कर सकता है या नहीं करेगा (उदाहरण के लिए, विकृत अनुरोध वाक्यविन्यास, अमान्य अनुरोध संदेश फ़्रेमिंग, या भ्रामक अनुरोध रूटिंग)।

---

हालाँकि, इससे पहले कि रि-वर्डिंग (या यदि आप RFC 7231 के बारे में केवल अभी एक प्रस्तावित मानक होना चाहते हैं) के बारे में जानना चाहते हैं, 422 Unprocessable Entityतो आपके उपयोग के मामले के लिए एक गलत HTTP स्थिति कोड नहीं लगता है , क्योंकि RFC 4918 के लिए परिचय कहता है:

जबकि HTTP / 1.1 द्वारा प्रदान की गई स्थिति कोड WebDAV विधियों द्वारा सामना की गई अधिकांश त्रुटि स्थितियों का वर्णन करने के लिए पर्याप्त है, कुछ त्रुटियां हैं जो मौजूदा श्रेणियों में बड़े करीने से नहीं आती हैं। यह विनिर्देश WebDAV विधियों (धारा 11) के लिए विकसित अतिरिक्त स्थिति कोड को परिभाषित करता है

और के विवरण422 का कहना है:

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

(सिंटैक्स के संदर्भ पर ध्यान दें; मुझे संदेह है कि 7231 आंशिक रूप से 4918 का भी पालन करता है)

यह बिल्कुल आपकी स्थिति की तरह लगता है, लेकिन सिर्फ मामले में कोई संदेह था, यह कहने के लिए जाता है:

उदाहरण के लिए, यह त्रुटि स्थिति तब हो सकती है जब किसी XML अनुरोध बॉडी में अच्छी तरह से गठित (यानी, वाक्यविन्यास रूप से सही) हो, लेकिन शब्दार्थ गलत, XML निर्देश।

("JSON" के साथ "XML" बदलें और मुझे लगता है कि हम सहमत हो सकते हैं कि आपकी स्थिति है)

अब, कुछ को आपत्ति होगी कि RFC 4918 "HTTP एक्सटेंशन्स फॉर वेब डिस्ट्रिब्यूटेड ऑथरिंग एंड वर्जनिंग (WebDAV)" के बारे में है और आप (संभवतया) WebDAV से जुड़े कुछ भी नहीं कर रहे हैं, इसलिए इससे चीजों का उपयोग नहीं करना चाहिए।

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

इसके अलावा, RFC 4918 धारा 21.4 IANA हाइपरटेक्स्ट ट्रांसफर प्रोटोकॉल (HTTP) स्टेटस कोड रजिस्ट्री को संदर्भित करता है , जहाँ 422 मिल सकते हैं।

मेरा प्रस्ताव है कि HTTP क्लाइंट या सर्वर के लिए उस रजिस्ट्री से किसी भी स्टेटस कोड का उपयोग करना पूरी तरह से उचित है, जब तक कि वे सही तरीके से ऐसा नहीं करते हैं।

---

लेकिन HTTP / 1.1 के अनुसार, RFC 7231 में कर्षण है, इसलिए बस उपयोग करें 400 Bad Request!

Comments

आपका जवाब (422) मुझे समझ में आता है। मान्यता त्रुटियों के कारण संसाधन संसाधित नहीं किए जाने पर यह वह भी है जो रेल ( प्रतिसाद ) का उपयोग करता है।

— टायलर रिक

गैर- WebDAV युक्ति में 422 के उपयोग पर ध्यान दें: tools.ietf.org/html/rfc5789#section-2.2

— एंड्री

अपडेट के रूप में, RFC 7231 में प्रतिक्रिया कोड 400 के लिए एक अलग विवरण है जो शब्दार्थ को बदलता है।

— ली सेफ़्रेइट

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

— क्रिस्टियन ग्लास

मुझे अभी भी लगता है कि कल्पना बहुत स्पष्ट हो सकती है। दिए गए उदाहरण क्लाइंट के कुछ गलत करने के स्पष्ट मामलों में हैं। ओपी की स्थिति भी उस श्रेणी में आती है। हालांकि, ऐसे मामले हैं जैसे "मैं समझता हूं कि आप क्या पूछ रहे हैं, लेकिन मैं इसे करने से इनकार करता हूं क्योंकि इसके खिलाफ कुछ व्यावसायिक नियम हैं" इतना स्पष्ट कटौती नहीं है। यह बिल्कुल ग्राहक की गलती नहीं है, इसलिए एक 403 वास्तव में एक ही कल्पना के अनुसार लागू हो सकता है: "हालांकि, क्रेडेंशियल्स से असंबंधित कारणों के लिए एक अनुरोध मना किया जा सकता है"। मैं अनुमति से संबंधित सामान के लिए अलग कोड रखना पसंद करूंगा "हालांकि यह नहीं किया जा सकता है"।

— थोरिन 19

Answer 2

400 बुरा अनुरोध आपके उपयोग के मामले के लिए उचित HTTP स्थिति कोड है। कोड HTTP / 0.9-1.1 RFC द्वारा परिभाषित किया गया है।

अनुरोध सर्वर द्वारा विकृत सिंटैक्स के कारण समझा नहीं जा सका। ग्राहक बिना संशोधनों के अनुरोध को नहीं दोहराएगा।

http://tools.ietf.org/html/rfc2616#section-10.4.1

422 असंसाधित इकाई को RFC 4918 द्वारा परिभाषित किया गया है - WebDav। ध्यान दें कि 400 की तुलना में थोड़ा अंतर है, नीचे उद्धृत पाठ देखें।

यह त्रुटि स्थिति तब हो सकती है जब किसी XML अनुरोध बॉडी में अच्छी तरह से गठित (यानी, वाक्यविन्यास रूप से सही) हो, लेकिन शब्दार्थ गलत, XML निर्देश।

वर्दी इंटरफ़ेस रखने के लिए आपको केवल XML प्रतिक्रियाओं के मामले में 422 का उपयोग करना चाहिए और आपको वेबदाव एक्सटेंशन द्वारा परिभाषित सभी स्टेटस कोड का भी समर्थन करना चाहिए, न कि केवल 422।

http://tools.ietf.org/html/rfc4918#page-78

स्टेटस कोड पर मार्क नॉटिंघम की पोस्ट भी देखें:

अपने एप्लिकेशन के प्रत्येक भाग को "गहराई" से HTTP स्थिति कोड में मैप करने का प्रयास करना एक गलती है; ज्यादातर मामलों में आप जिस उद्देश्य के लिए लक्ष्य बनाना चाहते हैं, उसका स्तर बहुत ही कठिन है। जब संदेह है, तो सामान्य स्थिति कोड 200 ठीक, 400 खराब अनुरोध और 500 आंतरिक सेवा त्रुटि का उपयोग करना ठीक है जब कोई बेहतर फिट नहीं है ।

HTTP स्टेटस कोड के बारे में कैसे सोचें

Comments

422 कोड IANA रजिस्ट्री का हिस्सा है iana.org/assignments/http-status-codes/http-status-codes.xhtml तो किसी भी IMHO का कोई मतलब नहीं है। किसी भी स्थिति में फेसबुक और ट्विटर रीस्ट एपीआई अपने कोड को फिर से मजबूत करते हैं और आरएफसी / आईएएनए मानकों का उपयोग नहीं करते हैं। तो आप कर सकते हैं।

— गवेंको

धारा 11 में विशेष रूप से कहा गया है कि वे संपूर्ण युक्ति में जोड़े जाते हैं, न कि केवल WebDav युक्ति के भीतर:The following status codes are added to those defined in HTTP/1.1 [RFC2616].

— स्टीव

सिर्फ इसलिए कि कोड को WebDAV के हिस्से के रूप में वर्णित किया गया है इसका मतलब यह नहीं है कि यह WebDAV- विशिष्ट है! स्थिति कोड सामान्य माना जाता है।

— अपने मॉड का अच्छी तरह से इलाज करें

Answer 3

2015 की स्थिति को प्रतिबिंबित करने के लिए:

व्यवहारिक रूप से 400 और 422 दोनों प्रतिक्रिया कोड ग्राहकों और बिचौलियों द्वारा एक ही माना जाएगा, इसलिए यह वास्तव में एक ठोस नहीं बनाता है आपके द्वारा उपयोग किए अंतर ।

हालाँकि मैं वर्तमान में 400 से अधिक व्यापक रूप से उपयोग किए जाने की उम्मीद करूंगा, और इसके अलावा HTTPbis कल्पना जो स्पष्टीकरण प्रदान करती है वह इसे दो स्थिति कोडों के लिए अधिक उपयुक्त बनाती है:

• HTTPbis कल्पना 400 के सिंटैक्स त्रुटियों के लिए पूरी तरह से नहीं होने के इरादे को स्पष्ट करती है। व्यापक वाक्यांश "इंगित करता है कि सर्वर अनुरोध को संसाधित नहीं कर सकता है या ऐसा कुछ करने के लिए अनुरोध नहीं करेगा, जिसे क्लाइंट त्रुटि माना जाता है" अब उपयोग किया जाता है।
• 422 विशेष रूप से एक WebDAV एक्सटेंशन है, और RFC 2616 में या नए HTTPbis विनिर्देश में संदर्भित नहीं है ।

संदर्भ के लिए, HTTPbis HTTP / 1.1 कल्पना का एक संशोधन है जो उन क्षेत्रों को स्पष्ट करने का प्रयास करता है जहां अस्पष्ट या असंगत हैं। एक बार जब यह स्वीकृत स्थिति में पहुँच जाता है तो यह RFC2616 को सुपरसेड करेगा।

Comments

क्या 403 निषिद्ध भी इस संदर्भ के लिए इस्तेमाल किया जा सकता है? उद्धरण: 403 (निषिद्ध) स्थिति कोड इंगित करता है कि सर्वर अनुरोध को समझ गया है, लेकिन इसे अधिकृत करने से इनकार करता है ... यदि अनुरोध में प्रमाणीकरण क्रेडेंशियल्स प्रदान किए गए थे, तो सर्वर उन्हें एक्सेस देने के लिए अपर्याप्त मानता है .... हालांकि, एक अनुरोध हो सकता है साख के लिए असंबंधित कारणों के लिए मना किया। इसलिए ऐसा लगता है कि प्रमाणीकरण के बाहर अनुरोधों को अस्वीकार करने के लिए 403 का उपयोग किया जा सकता है।

— कचरा पात्र

@garbagecollector ध्यान दें कि " क्रेडेंशियल के बाहर कारणों के लिए अस्वीकार कर दिया "! = " प्रमाणीकरण से बाहर के कारणों के लिए अस्वीकार कर दिया ।" विशेष रूप से क्रेडेंशियल्स का उपयोग किए बिना किसी को प्रमाणित करने के बहुत सारे तरीके हैं।

— केनेटिक

@garbagecollector नहीं, क्रेडेंशियल का अर्थ है प्रमाणीकरण ("आप कौन हैं"), जो विफलता पर 401 होगा। प्राधिकरण ("आप क्या कर सकते हैं") विफलता पर 403 होगा। यहां पूर्ण विवरण: stackoverflow.com/a/6937030/137948 न तो ओपी के "लापता क्षेत्रों" की स्थिति पर लागू होता है क्योंकि त्रुटि वही होगी जो उपयोगकर्ता ने प्रयास किया था। मैं मानता हूं कि 400 सही उत्तर है।

— विल शेपर्ड

Answer 4

केस स्टडी: गिटहब एपीआई

https://developer.github.com/v3/#client-errors

शायद जाने-माने API से कॉपी करना एक बुद्धिमान विचार है:

एपीआई कॉल पर तीन संभावित प्रकार की क्लाइंट त्रुटियाँ हैं जो अनुरोध निकाय प्राप्त करती हैं:

अमान्य JSON भेजने से 400 खराब अनुरोध प्रतिक्रिया होगी।

HTTP/1.1 400 Bad Request
Content-Length: 35

{"message":"Problems parsing JSON"}

गलत प्रकार के JSON मूल्यों को भेजने से 400 खराब अनुरोध प्रतिक्रिया होगी।

HTTP/1.1 400 Bad Request
Content-Length: 40

{"message":"Body should be a JSON object"}

अमान्य फ़ील्ड भेजने से 422 असंगत एंटिटी प्रतिसाद मिलेगा।

HTTP/1.1 422 Unprocessable Entity
Content-Length: 149

{
  "message": "Validation Failed",
  "errors": [
    {
      "resource": "Issue",
      "field": "title",
      "code": "missing_field"
    }
  ]
}

Comments

मुझे लगता है कि यह सही और समझने योग्य उत्तर है।

— LEMUEL ADANE

इसे और अधिक बढ़ा नहीं सकते। काश कि अधिक उत्कीर्ण उत्तर इस का उल्लेख करते। ऐनक (RFC, IANA) समय-समय पर दोनों के बीच स्पष्ट परिभाषा और भेद प्रदान करने में विफल रहे। तो इसका जवाब सबसे अच्छा तरीका है और GitHub हमें देता है।

— एलेक्स क्लॉज़

Answer 5

कोई सही उत्तर नहीं है, क्योंकि यह इस बात पर निर्भर करता है कि आपके अनुरोध के लिए "वाक्यविन्यास" की परिभाषा क्या है। सबसे महत्वपूर्ण बात यह है कि आप:

1. लगातार प्रतिक्रिया कोड का उपयोग करें
2. प्रतिक्रिया निकाय में उतनी ही अतिरिक्त जानकारी शामिल करें जितनी कि आप डेवलपर की सहायता के लिए कर सकते हैं कि आप क्या कर रहे हैं।

इससे पहले कि हर कोई यह कहने के लिए मेरे ऊपर कूद पड़े कि यहां कोई सही या गलत जवाब नहीं है, मुझे इस बारे में थोड़ा बताएं कि मैं कैसे निष्कर्ष पर आया।

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

जैसा कि मैंने ऊपर कहा, निर्णायक कारक वह है जो वाक्य रचना द्वारा होता है । यदि अनुरोध सामग्री प्रकार के साथ भेजा गया था application/json, तो हाँ, अनुरोध सिंथेटिक रूप से मान्य है क्योंकि यह JSON सिंटैक्स मान्य है, लेकिन शब्दार्थ मान्य है, क्योंकि यह मेल नहीं खाता है जो अपेक्षित है। (जो प्रश्न में अनुरोध को शब्दार्थिक रूप से मान्य है या नहीं है, इसकी सख्त परिभाषा देना)।

यदि, दूसरी ओर, अनुरोध को अधिक विशिष्ट कस्टम सामग्री प्रकार के साथ भेजा गया था application/vnd.mycorp.mydatatype+json , कि, शायद, वास्तव में क्या फ़ील्ड्स की अपेक्षा की जाती है, तो मैं कहूंगा कि अनुरोध आसानी से सिंथेटिक रूप से अमान्य हो सकता है, इसलिए 400 प्रतिक्रिया।

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

Comments

बहुत ही कम जवाब - अच्छी तरह से शब्द स्पष्टीकरण के लिए धन्यवाद।

— पुई

वास्तव में इस मामले पर मेरे विचार! मैं XML SOAP बैकग्राउंड से आ रहा हूं और स्कीमा की अवधारणा सिर्फ मेरे रक्त और JSON दस्तावेजों में मिली है, बल्कि अपने स्कीमा की घोषणा नहीं करते हैं। मेरे लिए यह है कि सर्वर अनुरोध को "समझता है" या नहीं। यदि सर्वर को यह पता नहीं है कि "sales_tax" क्या है तो यह केवल 400 है: "मुझे पता नहीं है कि आपने मुझे क्या भेजा है, लेकिन निश्चित रूप से मुझे वही चाहिए जो मुझे चाहिए।"

— अलेक्जेंडर स्टेलमज़ोनक

Answer 6

422 अप्राप्य इकाई की व्याख्या की गई: 6 मार्च, 2017

422 असंसाधित इकाई क्या है?

422 स्थिति कोड तब होता है जब कोई अनुरोध अच्छी तरह से बनता है, हालांकि, सिमेंटिक त्रुटियों के कारण इसे संसाधित करने में असमर्थ है। यह HTTP स्टेटस RFC 4918 में पेश किया गया था और यह विशेष रूप से वेब डिस्ट्रीब्यूटेड ऑथरिंग और वर्जनिंग (WebVAV) के लिए HTTP एक्सटेंशन की ओर तैयार है।

वहाँ कुछ विवाद है कि क्या डेवलपर्स को क्लाइंट के लिए 400 बनाम 422 त्रुटि वापस करनी चाहिए (अधिक नीचे दोनों स्थितियों के बीच अंतर पर)। हालाँकि, ज्यादातर मामलों में, इस बात पर सहमति है कि 422 स्थिति को केवल तभी लौटाया जाना चाहिए जब आप WebDAV क्षमताओं का समर्थन करते हैं।

RFC 4918 में धारा 11.2 से लिए गए 422 स्टेटस कोड की शब्द-दर-शब्द परिभाषा नीचे पढ़ी जा सकती है।

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

परिभाषा कहती है:

उदाहरण के लिए, यह त्रुटि स्थिति तब हो सकती है जब किसी XML अनुरोध बॉडी में अच्छी तरह से गठित (यानी, वाक्यविन्यास रूप से सही) हो, लेकिन शब्दार्थ गलत, XML निर्देश।

400 बनाम 422 स्थिति कोड

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

422 स्थिति का उपयोग केवल विशेष उपयोग के मामलों के लिए आरक्षित होना चाहिए। अधिकांश अन्य मामलों में जहां विकृत सिंटैक्स के कारण क्लाइंट त्रुटि हुई है, 400 खराब अनुरोध स्थिति का उपयोग किया जाना चाहिए।

https://www.keycdn.com/support/422-unprocessable-entity/

Answer 7

आपका मामला: HTTP 400 REST के दृष्टिकोण से आपके मामले के लिए सही स्थिति कोड sales_taxहै tax, क्योंकि इसकी वैध JSON है, हालांकि इसके बजाय भेजने के लिए सिंटैक्टिक रूप से गलत है । यह सामान्य रूप से सर्वर साइड फ्रेमवर्क द्वारा लागू किया जाता है, जब JSON को ऑब्जेक्ट्स पर मैप किया जाता है। हालाँकि, कुछ REST कार्यान्वयन हैं जो keyJSON ऑब्जेक्ट में नए को अनदेखा करते हैं । उस स्थिति में, content-typeकेवल मान्य फ़ील्ड स्वीकार करने के लिए एक कस्टम विनिर्देश सर्वर-साइड द्वारा लागू किया जा सकता है।

422 के लिए आदर्श परिदृश्य:

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

422 से अधिक 400 की स्थिति:

याद रखें, प्रतिक्रिया कोड 422 एक विस्तारित HTTP (WebDAV) स्थिति कोड है। अभी भी कुछ HTTP क्लाइंट / फ्रंट-एंड लाइब्रेरी हैं जो 422 को संभालने के लिए तैयार नहीं हैं। उनके लिए, "HTTP 422 गलत है, क्योंकि यह HTTP नहीं है" । सेवा के दृष्टिकोण से, 400 काफी विशिष्ट नहीं है।

एंटरप्राइज़ आर्किटेक्चर में, सेवाओं को ज्यादातर SOA, IDM, आदि जैसे सर्विस लेयर्स पर तैनात किया जाता है। वे आम तौर पर एक बहुत पुराने देशी क्लाइंट से लेकर एक नवीनतम HTTP क्लाइंट तक कई क्लाइंट्स की सेवा देते हैं। यदि क्लाइंट्स में से कोई HTTP 422 को हैंडल नहीं करता है, तो विकल्प हैं कि क्लाइंट को सबके लिए अपना प्रतिक्रिया कोड HTTP 400 में अपग्रेड करने या बदलने के लिए कह रहा है। मेरे अनुभव में, यह इन दिनों बहुत दुर्लभ है, लेकिन अभी भी एक संभावना है। तो, HTTP प्रतिसाद कोड पर निर्णय लेने से पहले आपकी वास्तुकला का सावधानीपूर्वक अध्ययन हमेशा आवश्यक है।

इस तरह की स्थिति को संभालने के लिए, सेवा परतें आमतौर पर 400 HTTP भेजने के लिए सख्त HTTP अनुरूपता ग्राहकों के लिए versioningया सेटअप configurationध्वज का उपयोग करती हैं , और उनमें से बाकी के लिए 422 भेजती हैं। इस तरह वे मौजूदा उपभोक्ताओं के लिए पश्चगामी संगतता सहायता प्रदान करते हैं, लेकिन साथ ही नए ग्राहकों के लिए HTTP 422 का उपभोग करने की क्षमता प्रदान करते हैं।

---

RFC7321 का नवीनतम अपडेट कहता है:

The 400 (Bad Request) status code indicates that the server cannot or
   will not process the request due to something that is perceived to be
   a client error (e.g., malformed request syntax, invalid request
   message framing, or deceptive request routing).

यह पुष्टि करता है कि सर्वर अमान्य अनुरोध के लिए HTTP 400 भेज सकते हैं। 400 अब केवल सिंटैक्स त्रुटि को संदर्भित नहीं करता है , हालांकि, 422 अभी भी एक वास्तविक प्रतिक्रिया है बशर्ते ग्राहक इसे संभाल सकें।

Answer 8

सबसे पहले यह एक बहुत अच्छा सवाल है।

400 बुरी रिक्वेस्ट - जब रिक्वेस्ट से क्रिटिकल इन्फॉर्मेशन गायब होती है

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

422 असंसाधित इकाई - जब अनुरोध निकाय को पार्स नहीं किया जा सकता है।

यह 400 से कम गंभीर है। अनुरोध सर्वर पर पहुंच गया है। सर्वर ने स्वीकार किया है कि अनुरोध को मूल संरचना सही मिली है। लेकिन अनुरोध निकाय की जानकारी को पार्स या समझा नहीं जा सकता है।

उदाहरण के लिए Content-Type: application/xmlजब अनुरोध JSON है।

यहां एक लेख सूची स्थिति कोड और REST API में इसका उपयोग किया गया है। https://metamug.com/article/status-codes-for-rest-api.php

Comments

422 का मतलब है कि वाक्यविन्यास वैध है, लेकिन सामग्री नहीं है। JSON भेजना जहां XML की उम्मीद है कि वाक्यविन्यास गलत है, इसलिए 400 इस मामले में सही प्रतिक्रिया है।

— डर्क

वास्तव में जैसा कि डिर्क ने कहा कि 422 का अर्थ है, सिन्थेटिकली वैलिड रिक्वेस्ट (पार्स और समझी जा सकती है) लेकिन शब्दार्थ से अमान्य

— जसेक ओबेरमस्की

400: जब अमान्य सिंटैक्स (जैसे पार्सिंग त्रुटि) के कारण अनुरोध को संसाधित नहीं किया जा सकता है; 422: जब अमान्य डेटा (जैसे सत्यापन त्रुटि) के कारण अनुरोध को संसाधित नहीं किया जा सकता है।

— कितनोत्री

422 के लिए आपका उदाहरण मान्य नहीं है क्योंकि आवेदन / xml मीडिया प्रकार के साथ json भेजकर, शरीर स्वचालित रूप से गलत रूप से गलत है और प्रतिक्रिया 400 होनी चाहिए।

— manemarron

Answer 9

आपको वास्तव में "200 ओके" वापस करना चाहिए और प्रतिक्रिया में शरीर में पोस्ट किए गए डेटा के साथ क्या हुआ, इसके बारे में एक संदेश शामिल है। फिर यह संदेश को समझने के लिए आपके आवेदन पर निर्भर है।

बात यह है, HTTP स्टेटस कोड बिल्कुल वही हैं - HTTP स्टेटस कोड। और इसका मतलब केवल ट्रांसपोर्ट लेयर पर होता है, एप्लीकेशन लेयर पर नहीं। एप्लिकेशन परत को वास्तव में कभी भी पता नहीं होना चाहिए कि HTTP का उपयोग किया जा रहा है। यदि आपने अपनी परिवहन परत को HTTP से Homing Pigeons में बदल दिया है, तो यह किसी भी तरह से आपकी एप्लिकेशन परत को प्रभावित नहीं करना चाहिए।

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

1. आप सड़क का नाम लिखना भूल गए। आपको एक अप्रकाशित पत्र वापस मिलेगा, जिसमें यह लिखा होगा कि पता विकृत है। आपने अनुरोध को भांप लिया और प्राप्त डाकघर इसे संभालने में असमर्थ है। यह "400 खराब अनुरोध" प्राप्त करने के बराबर है।
2. इसलिए आप पते को ठीक करें और फिर से पत्र भेजें। लेकिन कुछ बुरी किस्मत के कारण आपने गली के नाम को याद नहीं किया। आपको यह कहते हुए पत्र वापस मिल जाएगा कि संदेश मौजूद नहीं है। यह "404 नहीं मिला" प्राप्त करने के बराबर है।
3. आप फिर से पते को ठीक करते हैं और इस बार आप पते को सही ढंग से लिखने का प्रबंधन करते हैं। आपकी लड़की पत्र प्राप्त करती है और आपको वापस लिखती है। यह "200 ओके" प्राप्त करने के बराबर है। हालांकि, इसका मतलब यह नहीं है कि आपको वह पसंद आएगा जो उसने अपने पत्र में लिखा है। इसका सीधा सा मतलब है कि उसे आपका संदेश मिला है और आपके लिए उसकी प्रतिक्रिया है। जब तक आप लिफाफा खोलते हैं और उसके पत्र को पढ़ते हैं, तब तक आप यह नहीं जान सकते कि वह आपको बहुत याद करती है या आपसे संबंध तोड़ना चाहती है।

संक्षेप में: "200 ठीक" लौटने का मतलब यह नहीं है कि सर्वर ऐप आपके लिए अच्छी खबर है। इसका मतलब केवल यह है कि इसमें कुछ खबरें हैं।

PS: 422 स्टेटस कोड का अर्थ केवल WebDAV के संदर्भ में है। यदि आप WebDAV के साथ काम नहीं कर रहे हैं, तो 422 का किसी अन्य गैर-मानक कोड के समान मानक अर्थ है = जो कोई नहीं है।