असफल सत्यापन या अमान्य डुप्लिकेट के लिए REST HTTP स्थिति कोड

Question

मैं REST- आधारित API के साथ एक एप्लिकेशन बना रहा हूं और उस बिंदु पर आ गया हूं जहां मैं प्रत्येक अनुरोधों के लिए स्टेटस कोड निर्दिष्ट कर रहा हूं।

सत्यापन को विफल करने वाले अनुरोधों के लिए मुझे क्या स्थिति कोड भेजना चाहिए या एक अनुरोध मेरे डेटाबेस में डुप्लिकेट जोड़ने का प्रयास कर रहा है?

मैंने http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html के माध्यम से देखा है, लेकिन उनमें से कोई भी सही नहीं लगता है।

क्या स्टेटस कोड भेजते समय एक आम बात है?

Comments

देखें: stackoverflow.com/questions/1959947/…

— dea

ओपन httpstatus.es , राइट क्लिक >> पिन टैब: पी

— सलमान वॉन अब्बास

के संभावित डुप्लिकेट क्या एक उपयुक्त HTTP स्थिति एक सत्यापन विफलता के लिए एक REST API सेवा से वापस जाने के लिए कोड है?

— एंड्रीमोनी

Answer 1

इनपुट सत्यापन विफलता के लिए: 400 खराब अनुरोध + आपका वैकल्पिक विवरण। यह " रेस्टफुल वेब सर्विसेज " पुस्तक में सुझाया गया है । डबल जमा के लिए: 409 संघर्ष

---

जून 2014 को अपडेट करें

प्रासंगिक विनिर्देश RFC2616 हुआ करता था , जिसने 400 (बैड रिक्वेस्ट) के उपयोग को संकीर्ण रूप में दिया

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

तो यह तर्क दिया जा सकता है कि यह शब्दार्थ त्रुटियों के लिए अनुचित था। लेकिन अब और नहीं; जून 2014 के बाद से प्रासंगिक मानक RFC 7231 , जो पिछले RFC2616 को उलट देता है, 400 का उपयोग करता है (खराब अनुरोध) अधिक व्यापक रूप से

क्लाइंट किसी क्लाइंट त्रुटि के कारण कुछ के कारण अनुरोध को संसाधित नहीं कर सकता है या नहीं करेगा

Comments

हां, अनुरोध निकाय वाक्य रचना का हिस्सा है।

— बहरीन

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

— डारेल मिलर

तो आप विकृत डेटा के बीच अंतर कैसे करते हैं कि सर्वर भी पार्स नहीं कर सकता है, और एक सत्यापन त्रुटि? एक ग्राहक इन दो प्रतिक्रियाओं को पूरी तरह से अलग तरीके से संभालता है। सत्यापन के लिए, वे संभवतः उपयोगकर्ता को त्रुटियों को प्रदर्शित करेंगे। सही मायने में "विकृत डेटा" के लिए, वे त्रुटि लॉग करेंगे ताकि विधि उत्पन्न करने वाले बग में अनुरोध को ठीक किया जा सके।

— जोश नूर

मैं RFC7231 की आपकी व्याख्या से असहमत हूं, हालांकि यह बताता है something perceived to be a client error, इस पैराग्राफ में दिए गए सभी उदाहरण HTTP प्रोटोकॉल के उल्लंघन हैं, न कि तार्किक त्रुटियां: वाक्यविन्यास, फ़्रेमिंग, रूटिंग। इस प्रकार, मैं समझता हूं कि HTTP स्‍पष्‍टीकरण के लिए आवेदन स्‍तर पर विफल सत्यापन के लिए 400 की अनुमति नहीं है।

— दिमा तिस्नेक

एक 422 का उपयोग क्यों नहीं करें - अनुत्पादक इकाई? मेरे लिए अधिक तार्किक लगता है

— java_geek

Answer 2

• विफल सत्यापन: 403 निषिद्ध ("सर्वर अनुरोध को समझ गया, लेकिन इसे पूरा करने से इनकार कर रहा है")। आम राय के विपरीत, RFC2616 यह नहीं कहता कि "403 केवल असफल प्रमाणीकरण के लिए है", लेकिन "403: मुझे पता है कि आप क्या चाहते हैं, लेकिन मैं ऐसा नहीं करूंगा"। प्रमाणीकरण के कारण यह स्थिति हो सकती है या नहीं भी हो सकती है।
• डुप्लिकेट जोड़ने की कोशिश: 409 संघर्ष ("संसाधन के वर्तमान के साथ संघर्ष के कारण अनुरोध पूरा नहीं किया जा सका।")

आपको निश्चित रूप से प्रतिक्रिया हेडर और / या बॉडी में अधिक विस्तृत विवरण देना चाहिए (जैसे एक कस्टम हेडर के साथ - X-Status-Reason: Validation failed)।

Comments

@ डायमॉन: यह विनिर्देश नहीं है, यह विकिपीडिया है, अर्थात "HTTP स्थिति कोड का क्या अर्थ है" पर किसी की राय; ध्यान दें कि आवश्यक पेज कहता है "यह अपाचे का मतलब है 403 के साथ, यह वही है जो आईआईएस का मतलब है 403 के साथ", और कहीं भी यह आधिकारिक आरएफसी का संदर्भ नहीं देता है। आपको लगता है कि "अपाचे जो भी कहता है" 403 का अर्थ है। नहीं। वास्तविक RFC (जो प्रासंगिक दस्तावेज़ है, अपाचे का कार्यान्वयन नहीं, IIS का कार्यान्वयन नहीं, किसी और का कार्यान्वयन नहीं है) यहाँ है: w3.org/Protocols/rfc2616/rfc2616-sec10.html

— Piskvor ने इमारत

10. 10.4.4 403 निषिद्ध सर्वर ने अनुरोध को समझा, लेकिन इसे पूरा करने से इनकार कर रहा है। प्राधिकरण मदद नहीं करेगा और अनुरोध को दोहराया नहीं जाएगा। यदि अनुरोध विधि HEAD नहीं थी और सर्वर सार्वजनिक करना चाहता है तो अनुरोध क्यों नहीं है। पूरा किया गया है, यह इकाई में इनकार के कारण का वर्णन करता है। यदि सर्वर ग्राहक को यह जानकारी उपलब्ध कराने की इच्छा नहीं रखता है, तो इसके बजाय स्थिति कोड 404 (नहीं मिला) का उपयोग किया जा सकता है। " मुझे वहां कोई जोर नहीं दिखता ("SHOULD / SHOULD NOT" RFC 2119 कीवर्ड हैं, जोर नहीं); यह आपका विचार है कि "निषिद्ध" का अर्थ है, RFC का नहीं।

— पिस्कोर ने

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

— पैब्लोबम

त्रुटि संदेश के लिए आपको कारण वाक्यांश को संशोधित करना चाहिए, इसलिए हेडर भेजना HTTP/1.0 403 Form validation errorsसबसे साफ तरीका है।

— 13

IMO, 422 "अनप्रोसेबल एंटिटी" बहुत अधिक समझ में आता है। मेरा तर्क यह है कि ऐसा नहीं है कि सर्वर अनुरोध को पूरा करने से इनकार करता है, यह है कि सर्वर अनुरोध को पूरा नहीं कर सकता है ।

— tybro0103

Answer 3

मैं स्थिति कोड 422, "असंसाधित इकाई" की सिफारिश करता हूं ।

11.2। 422 असंसाधित इकाई

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

Comments

बेशक यह एक HTTP स्टेटस कोड है, देखें iana.org/assignments/http-status-codes । RFC 2616 में परिभाषित लोगों की तुलना में अधिक स्टेटस कोड हैं।

— जूलियन

WebDAV एक HTTP एक्सटेंशन है । "वेब डिस्ट्रिब्यूटेड ऑथरिंग एंड वर्जनिंग (वेबडीएवी) के लिए HTTP एक्सटेंशन्स" इसलिए, स्टेटस कोड 422 एक http स्टेटस कोड नहीं है, लेकिन http के एक्स्टेंशन का स्टेटस कोड है।

— बहरीन जुएल

बहरा, कि कोई मतलब नहीं है। HTTP परिभाषित करता है कि नए कोड को कैसे परिभाषित किया जाए, और यही WebDAV कर रहा है। एक कारण के लिए एक स्थिति कोड रजिस्ट्री है।

— जूलियन रेसके जूल

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

— स्टीव कालस्टैड

और धागे 'एक्सपायर' नहीं होते। उन्हें जीवित रहने की आवश्यकता है या शीर्ष Google खोज परिणाम गलत होने लगते हैं।

— जेम्स बिलिंगहैम

Answer 4

200,300, 400, 500 सभी बहुत सामान्य हैं। यदि आप सामान्य चाहते हैं, तो 400 ठीक है।

422 का उपयोग एपीआई की बढ़ती संख्या द्वारा किया जाता है, और यहां तक ​​कि रेल द्वारा बॉक्स से बाहर भी उपयोग किया जाता है।

कोई फर्क नहीं पड़ता कि आप अपने एपीआई के लिए कौन सी स्थिति कोड चुनते हैं, कोई असहमत होगा। लेकिन मैं 422 पसंद करता हूं क्योंकि मैं '400 + टेक्स्ट स्टेटस' के बारे में सोचता हूं। इसके अलावा, आप एक JSON- तैयार पार्सर का लाभ नहीं उठा रहे हैं; इसके विपरीत, एक JSON प्रतिक्रिया के साथ एक 422 बहुत स्पष्ट है, और त्रुटि जानकारी का एक बड़ा सौदा अवगत कराया जा सकता है।

JSON प्रतिक्रिया की बात करते हुए, मैं इस मामले के लिए रेल त्रुटि प्रतिक्रिया पर मानकीकरण करता हूं, जो है:

{
    "errors" :
    { 
        "arg1" : ["error msg 1", "error msg 2", ...]
        "arg2" : ["error msg 1", "error msg 2", ...]
    }
}

यह प्रारूप प्रपत्र सत्यापन के लिए एकदम सही है, जिसे मैं 'त्रुटि रिपोर्टिंग समृद्धि' के संदर्भ में समर्थन के लिए सबसे जटिल मामला मानता हूं। यदि आपकी त्रुटि संरचना यह है, तो यह संभवतः आपकी सभी त्रुटि रिपोर्टिंग आवश्यकताओं को संभाल लेगा।

Comments

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

— योना

मैं यह नहीं सोचता; बस एक है कि रिश्ते के लिए प्रकट होता है उठाओ।

— सेटहॉल

या यहां तक ​​कि दोनों args पर सिर्फ त्रुटि। एक उपयोगकर्ता के रूप में, मुझे लगता है कि मैं प्रत्येक ऐसे क्षेत्र में त्रुटि देखना चाहता हूं जो परस्पर विरोधी हैं, मुझे लगता है।

— snuggles

नाइस !. स्पष्ट रूप से निहित से बेहतर है

— bhathiya-perera

Answer 5

200

ऊग ... (309, 400, 403, 409, 415, 422) ... बहुत सारे उत्तर अनुमान लगाने, बहस करने और एक सफल HTTP अनुरोध के लिए सबसे अच्छा रिटर्न कोड है, लेकिन एक असफल रीस्ट कॉल के लिए मानकीकरण करने की कोशिश कर रहे हैं ।

यह है गलत HTTP स्थिति कोड और बाकी स्थिति कोड मिश्रण।

हालाँकि, मैंने कई कार्यान्वयनों को मिलाते हुए देखा, और कई डेवलपर्स मुझसे सहमत नहीं हो सकते हैं।

HTTP रिटर्न कोड HTTP Requestखुद से संबंधित हैं । एक REST कॉल हाइपरटेक्स्ट ट्रांसफर प्रोटोकॉल अनुरोध का उपयोग करके किया जाता है और यह अपने आप में लागू REST विधि की तुलना में निम्न स्तर पर काम करता है। REST एक अवधारणा / दृष्टिकोण है, और इसका आउटपुट एक व्यावसायिक / तार्किक परिणाम है, जबकि HTTP परिणाम कोड एक परिवहन है।

उदाहरण के लिए, जब आप कॉल करते हैं, तो "404 नहीं मिला" वापस लौटते हैं / उपयोगकर्ताओं को भ्रमित करते हैं, क्योंकि इसका मतलब हो सकता है:

• URI गलत है (HTTP)
• कोई उपयोगकर्ता नहीं मिला (REST)

"403 निषिद्ध / पहुँच निषेध" का अर्थ हो सकता है:

• विशेष अनुमति की आवश्यकता है। उपयोगकर्ता / पासवर्ड पूछकर ब्राउज़र इसे संभाल सकते हैं। (एचटीटीपी)
• सर्वर पर गलत पहुंच अनुमतियाँ कॉन्फ़िगर की गई हैं। (एचटीटीपी)
• आपको प्रमाणित होना चाहिए (REST)

और सूची '500 सर्वर त्रुटि' (Apache / Nginx HTTP फेंकी गई त्रुटि या REST में व्यावसायिक बाधा त्रुटि) या अन्य HTTP त्रुटियों आदि के साथ जारी रह सकती है ...

कोड से, यह समझना मुश्किल है कि विफलता का कारण क्या था, HTTP (परिवहन) विफलता या REST (तार्किक) विफलता।

यदि HTTP अनुरोध भौतिक रूप से सफलतापूर्वक किया गया था, तो उसे हमेशा 200 कोड वापस करना चाहिए , भले ही रिकॉर्ड पाया गया हो या नहीं। क्योंकि URI संसाधन पाया और HTTP सर्वर द्वारा नियंत्रित किया गया था। हां, यह एक खाली सेट लौटा सकता है। क्या HTTP परिणाम के रूप में 200 के साथ एक खाली वेब-पेज प्राप्त करना संभव है, है ना?

इसके बजाय आप कुछ विकल्पों के साथ 200 HTTP कोड वापस कर सकते हैं:

• JSON परिणाम में "त्रुटि" ऑब्जेक्ट यदि कुछ गलत हो जाता है
• यदि कोई रिकॉर्ड नहीं मिला तो JSON सरणी / ऑब्जेक्ट खाली करें
• एक बेहतर परिणाम के लिए पिछले विकल्पों के साथ संयोजन में एक बूल परिणाम / सफलता ध्वज।

साथ ही, कुछ इंटरनेट प्रदाता आपके अनुरोधों को रोक सकते हैं और आपको 404 HTTP कोड लौटा सकते हैं। इसका मतलब यह नहीं है कि आपका डेटा नहीं मिला है, लेकिन यह परिवहन स्तर पर कुछ गलत है।

से विकी :

जुलाई 2004 में, यूके टेलीकॉम प्रदाता बीटी ग्रुप ने क्लीनफीड कंटेंट ब्लॉकिंग सिस्टम की तैनाती की, जो कि इंटरनेट वॉच फाउंडेशन द्वारा संभावित रूप से अवैध रूप से पहचानी गई सामग्री के लिए किसी भी अनुरोध पर 404 त्रुटि देता है। अन्य ISP समान परिस्थितियों में HTTP 403 "निषिद्ध" त्रुटि लौटाते हैं। थाईलैंड और ट्यूनीशिया में सेंसरशिप छुपाने के साधन के रूप में नकली 404 त्रुटियों को नियोजित करने की प्रथा भी बताई गई है। ट्यूनीशिया में, जहां 2011 की क्रांति से पहले सेंसरशिप गंभीर थी, लोग नकली 404 त्रुटियों की प्रकृति से अवगत हुए और "अम्मर 404" नामक एक काल्पनिक चरित्र बनाया, जो "अदृश्य सेंसर" का प्रतिनिधित्व करता है।

बस कुछ इस तरह से जवाब क्यों नहीं?

{
  "result": false,
  "error": {"code": 102, "message": "Validation failed: Wrong NAME."}
}

Google हमेशा अपने जियोकोडिंग एपीआई में 200 को स्टेटस कोड के रूप में देता है, भले ही अनुरोध तार्किक रूप से विफल हो: https://developers.google.com/maps/documentation/geocoding/intro#StatusCodes

सफल HTTP अनुरोधों के लिए Facebook हमेशा 200 वापस करता है, भले ही REST अनुरोध विफल हो: https://developers.facebook.com/docs/graph-api/use-graph-api/error-handling

यह सरल है, HTTP स्थिति कोड HTTP अनुरोधों के लिए हैं। REST API आपका है, आपकी स्थिति कोड परिभाषित करें।

Comments

वास्तव में, REST के लिए HTTP स्टेटस कोड का उपयोग करना सड़क पर और भी अधिक भ्रमित करने वाला है: 1) आप अपने डेवलपर के टूलबॉक्स में 4xx देखते हैं और आप इस पर केवल यह देखकर नहीं कह सकते कि क्या सर्वर ने कुछ समझदार मूल्य लौटाया या आपके अनुरोध को पूरा करने में विफल रहा और फिर 2) आपकी सभी त्रुटि / अपवाद / कैच हैंडलर को यह जांचना चाहिए कि सर्वर किस प्रतिक्रिया के रूप में लौटा है (ज्यादातर वे तब से नहीं करते हैं जब तक कि आप इसे प्रत्येक सेवा कॉल पर नहीं करना चाहते) और कई बार 3) आपको एक ही पेलोड मिलता है () प्रकार) दोनों सफलता और त्रुटि पथ पर जटिल / डुप्लिकेट कोड के लिए अग्रणी ... वास्तव में बहुत भ्रामक।

— szczepanpp

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

— केविन हूके

@Marcodor यदि आपका API कॉल विफल हो जाता है लेकिन आप 200 को सफलता का संकेत देते हैं, तो यह एक अच्छा विचार कैसे है? यह आपके API के उपभोक्ताओं के लिए अस्पष्ट और भ्रमित करने वाला है।

— केविन हुक

कई कारणों से सही, न केवल HTTP बनाम REST त्रुटियों के अलगाव। REST सत्यापन को अक्सर अधिक बारीकियों की आवश्यकता होती है। उदाहरण के लिए, रिकॉर्ड को स्वीकार किया गया लेकिन एक अद्वितीय सूचकांक उल्लंघन के लिए डुप्लिकेट बनाम अस्वीकृत के रूप में चिह्नित किया गया। आप एक सुसंगत रिटर्न मॉडल भी चाहते हैं। .NET BadRequest()विधि का अपना रिटर्न मॉडल है जो आपके नियमित रिटर्न मॉडल से अलग होगा। यह एक बुरा सपना है। @KevinHooke, REST सत्यापन त्रुटि के लिए HTTP 200 वापस करना यह कहने जैसा है, "मुझे आपका संदेश प्राप्त हुआ, उत्तर नहीं है, और यहाँ क्यों है।" HTTP 400 लौटाते हुए कहते हैं, "मुझे नहीं पता कि तुम किस बारे में बात कर रहे हो।"

— नील लेसलेट

"क्योंकि Google यह करता है, यह सही होना चाहिए" तर्क मेरे लिए पागल है..कुछ को चुनौती देने के लिए ठीक है कि Google ने बच्चों को लागू किया है। एक असफल रेस्ट कॉल के लिए HTTP 200 को वापस करना एपीआई के कॉल करने वाले को भ्रमित करता है कि यह 4xx होना चाहिए और शरीर में एक सुंदर JSON / XML शामिल हो सकता है ... एक साथ पागलपन को रोकने देता है।

— जेरिल कुक

Answer 6

डेटाबेस में एक डुप्लिकेट होना चाहिए 409 CONFLICT।

मैं 422 UNPROCESSABLE ENTITYसत्यापन त्रुटियों के लिए उपयोग करने की सलाह देता हूं ।

मैं यहां 4xx कोड्स की लंबी व्याख्या देता हूं ।

Answer 7

स्थिति कोड 304 संशोधित नहीं एक डुप्लिकेट अनुरोध के लिए एक स्वीकार्य प्रतिक्रिया भी होगी। यह If-None-Matchएक इकाई टैग का उपयोग करने के शीर्ष लेख को संसाधित करने के समान है ।

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

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

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

Comments

यह मेरी समझ थी कि 304 जीईटी संचालन के लिए कैशिंग के साथ सहायता करने के लिए है।

— सिनास्टैटिक

Answer 8

Ember-Data का ActiveRecord एडॉप्टर 422 UNPROCESSABLE ENTITYसर्वर से वापस आने की उम्मीद करता है। इसलिए, यदि आप क्लाइंट में Ember.js में लिखे गए हैं, तो आपको 422 का उपयोग करना चाहिए। उसके बाद ही DS.Errors को लौटी त्रुटियों के लिए आबाद किया जाएगा। आप अपने एडॉप्टर में किसी अन्य कोड में 422 को बदल सकते हैं ।