"थिंग नहीं मिला" के लिए मुझे क्या एचटीपी कोड वापस करना चाहिए?

Question

मैं एक विशेष सेवा में, एक संरक्षक के बारे में जानकारी मांगने के लिए उपयोग की जाने वाली एक वेब-सेवा का निर्माण कर रहा हूं।

के तर्क की खातिर कहते हैं, यह है कि देखने वेब हिट है चलो:

GET /patrons/619 HTTP/1.1 

तो संरक्षक पाया जाता है, मैं वापस कोड 200:

HTTP/1.1 200 OK 

आप छोड़ देते हैं, तो या एक खाता संख्या दें जो संख्या नहीं है, मैं 400 लौटाता हूं। उदाहरण के लिए निम्नलिखित खराब अनुरोध:

GET /patrons HTTP/1.1 
GET /patrons/ HTTP/1.1 
GET /patrons/G619 HTTP/1.1 
GET /patrons/kirsten%20guyer HTTP/1.1 

सभी वापसी त्रुटि 400 (ख़राब अनुरोध), उदा .:

HTTP/1.1 400 Invalid patron number 

---

मैं नहीं मिला संरक्षक के लिए स्थिति कोड के लिए चाहते हैं, HTTP स्थिति कोड के रूप में लौट आए। उदाहरण के लिए:

GET /patrons/1322 HTTP/1.1 

HTTP/1.1 404 Not Found 

मैं 404 (नहीं मिला), जो है एक वैध प्रतिक्रिया (। अनुरोध किया गया संसाधन था, वास्तव में और वास्तव में, नहीं मिला) का उपयोग कर के बारे में सोचा है लेकिन मैं डर लग रहा है लोग इसे डिबग करने से सोच सकते हैं कि इसका मतलब है कि उन्होंने /patrons/ गलत लिखा है।

क्या कोई अन्य http स्टेटस कोड के बारे में सोच सकता है जिसका मैं उपयोग कर सकता हूं?

---

अद्यतन: मैं

204 No Content 
The server successfully processed the request, but is not returning any content. 

eyeballing कर रहा हूँ तुम क्या कहना?

---

भूलें नहीं, कि सभी HTTP सर्वर HTML सामग्री को पूरा नहीं करते हैं। यदि एक आईआईएस वेब-सर्वर से संसाधन के लिए कहा जाता है:

GET /MyStartPage.html HTTP/1.1 

तब HTTP सर्वर को यह तय करना होगा कि किसके साथ जवाब देना है। अधिकांश वेब-सर्वर पर, /MyStartPage.html नामक एक संसाधन हार्ड ड्राइव पर बैठे फ़ाइल से मेल खाता है।

StackOverflow जबकि करता है:

GET /posts/1027301 HTTP/1.1 

किस, यदि उस संसाधन मौजूद नहीं है, वेब सर्वर (ठीक ही) वापसी 404.

Answer 1

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

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

एक 500 लौटने पर जब एप्लिकेशन यह करने के लिए डिज़ाइन किया गया है तो यह थोड़ा अजीब लगता है। 404 बिल्कुल स्थिति का वर्णन करता है: संसाधन नहीं मिला।

Answer 2

IMHO, HTTP प्रतिसाद नहीं है चाहिए इसे संभालने के लिए उचित स्थान, क्योंकि त्रुटि HTTP स्तर पर नहीं है। यह आवेदन स्तर पर है। एक संभावित समाधान Null Object Pattern का उपयोग करने के लिए एक नल 'संरक्षक' वापस करने के लिए है जो संरक्षक इंटरफ़ेस के अनुरूप है, लेकिन इंगित करता है कि ऐसा कोई व्यक्ति मौजूद नहीं है।

---

अद्यतन: मैं आश्वस्त किया गया है कि इस जवाब गलत है। हालांकि, मैं इसे छोड़ना चाहता हूं, क्योंकि यह एक संभावित वैध उत्तर है (प्रश्न में प्रस्तुत किए गए विवरणों के आधार पर), और मुझे लगता है कि टिप्पणियां निर्देशक हैं।

Answer 3

आमतौर पर यदि आपकी सेवा में कोई त्रुटि आती है जो इसे संभालने में असमर्थ है, लेकिन अनुरोध अच्छी तरह से गठित है, तो मुझे लगता है कि आप 500 स्थिति कोड वापस करना चाहते हैं।

इसके अलावा, एक और कारण है कि मैं 500 कहूंगा कि यह उचित होगा कि .NET वेब सेवाओं में मेरे अनुभव से, जब भी मैं तार में एक अपवाद फेंकता हूं (जैसे रिकॉर्ड नॉटफाउंड अपवाद), वेब सर्वर और क्लाइंट हमेशा व्याख्या करता है 500 स्थिति कोड होने का जवाब।

किसी भी तरह से, http स्थिति कोडों के list की समीक्षा करना एक अच्छा विचार होगा, और जो आपकी आवश्यकताओं को सर्वोत्तम बनाता है उसे ठीक करें।

Answer 4

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

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

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

404 एकमात्र उचित प्रतिक्रिया है, जब तक कि आप इसे पूरी तरह से वैध अनुरोध पर विचार नहीं करना चाहते हैं, वापसी की स्थिति 200 और एक पृष्ठ समझाते हुए अनुरोध किया गया है कि अनुरोधित संरक्षक मौजूद नहीं है।

सवाल पर अपने मूल टिप्पणी से :

मुझे नहीं लगता कि यह है कि एक 200-स्तर की त्रुटि या तो उचित होगा, डब्ल्यू 3 w3.org/Protocols/rfc2616/rfc2616-sec10.html पर

Answer 5

मुझे लगता है कि विवरणों पर विचार आपको 404 का उपयोग करना चाहिए। एपीआई के डेवलपर्स समझेंगे कि 404 का मतलब क्या है और इसलिए समस्या को हल करने के लिए अपनी सामान्य डीबगिंग प्रक्रिया का पालन करेंगे। प्रोटोकॉल पर चिपकाओ।

Answer 6

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

Answer 7

यह इस बात पर निर्भर करता है कि आप किस प्रकार की webservice बना रहे हैं।

एसओएपी और एक्सएमएल वेबसाइसेस आमतौर पर 200 ओके वापस लौटाते हैं यदि अनुरोधित ऑब्जेक्ट (संरक्षक) नहीं मिला और प्रतिक्रिया दस्तावेज़ में त्रुटि प्रकार/संदेश/विवरण एन्कोड किया जा सकता है। वे एक्सचेंज किए गए संदेशों (एक्सएमएल) से एक परिवहन स्तर (HTTP) अलग करते हैं। यदि आप एक गैर-मौजूदा API एंडपॉइंट (गलत यूआरएल) का अनुरोध करते हैं तो 404 त्रुटि (जो परिवहन स्तर पर है) केवल तभी लौटा दी जाती है।

एक आरईएसटी webservice के साथ, आप सीधे संदेश विनिमय के लिए HTTP विधियों और स्थितियों का उपयोग करते हैं। आरईएसटी अलग-अलग HTTP विधियों का उपयोग करता है (GET/POST/PUT/DELETE) यह निर्दिष्ट करने के लिए कि कौन सी कार्रवाई चाहता है और सर्वर स्थिति को HTTP स्थिति के रूप में देता है। तो एक आरईएसटी webservice के मामले में, यदि कोई संरक्षक नहीं मिला तो 404 उचित HTTP स्थिति होगी।

500 मुझे लगता है कि किसी भी मामले में अनुचित है, क्योंकि 5xx का मतलब है कि सर्वरसाइड पर कुछ गलत है (जो मामला नहीं है) जबकि 4xx त्रुटियों का मतलब है कि क्लाइंट पक्ष में कुछ गड़बड़ है।

Answer 8

यदि आप HTTP प्रतिक्रिया कोड के माध्यम से वेब सेवा के प्रतिक्रियाओं को नियंत्रित करना चाहते हैं, तो आप वास्तव में इस स्थिति को इंगित करने के लिए 404 का उपयोग कर सकते हैं।

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

मैं परंपरागत में अपवादों के समान गैर-200 त्रुटि कोड मानता हूं प्रोग्रामिंग भाषाएं, और HTTP प्रतिक्रिया निकाय रिटर्न कोड की तरह अधिक है। कल्पना करें कि क्या आप इसे पारंपरिक रूप से कार्यान्वित कर रहे थे - यदि कोई इकाई नहीं मिली है, या null वापस लौटाएंगे तो क्या आप अपवाद फेंक देंगे? व्यक्तिगत रूप से, नेटवर्क कनेक्शन की नाजुक प्रकृति को देखते हुए, मैं संचार में समस्याओं के लिए सभी HTTP-स्तरीय त्रुटि कोड आरक्षित करना चाहता हूं, और परिणामस्वरूप या किसी भी सेवा को निर्दिष्ट करने वाले पेलोड के साथ ही मैं हमेशा सेवा से 200 OK वापस कर दूंगा -वेल त्रुटि।

Answer 9

यह 4 साल का हो सकता है लेकिन यह अभी भी काफी प्रासंगिक है। एपीआई के लिए जो दोनों borwsers और देशी ऐप्स द्वारा उपयोग किया जाना है, मुझे लगता है कि स्थिति संकेत के लिए HTTP कोड का उपयोग करना बहुत आसान है। और यदि आवश्यक हो तो उन गैर-आवंटित लोगों से उन अतिरिक्त शर्तों के लिए कुछ अतिरिक्त कोड का उपयोग करें जिनके पास मौजूदा HTTP कोड के लिए उपयुक्त नहीं है।