मैं कहूंगा, न तो वास्तव में उचित है। जैसा कि कहा गया है - जैसे @anneb द्वारा, मुझे भी लगता है कि समस्याओं का हिस्सा एक HTTP प्रतिक्रिया कोड का उपयोग करने से उत्पन्न स्थिति से संबंधित स्थिति का परिवहन करने के लिए होता है। REST सेवा के बारे में कुछ भी कहना है कि इसके स्वयं के प्रसंस्करण के बारे में REST के विशिष्ट कोड के माध्यम से परिवहन किया जाना चाहिए।
1
मेरा तर्क है कि, यदि HTTP सर्वर को कोई ऐसी सेवा मिलती है, जो भेजे गए अनुरोध का उत्तर देने के लिए तैयार है, तो उसे HTTP 404 के साथ जवाब नहीं देना चाहिए - अंत में, सर्वर द्वारा कुछ पाया गया - जब तक कि स्पष्ट रूप से ऐसा नहीं बताया गया सेवा जो अनुरोध को संसाधित करती है।
चलिए एक पल के लिए निम्न URL मान लेते हैं http://example.com/service/return/test:।
- केस ए यह है कि सर्वर "फ़ाइल सिस्टम पर फ़ाइल की तलाश में है"। यदि यह मौजूद नहीं है,
404तो सही है। यह सच है, अगर यह फ़ाइल को वितरित करने के लिए किसी प्रकार की सेवा पूछता है और यह सेवा यह बताती है कि उस नाम का कुछ भी मौजूद नहीं है।
- मामले में बी, सर्वर "वास्तविक" फाइलों के साथ काम नहीं करता है, लेकिन वास्तव में अनुरोध किसी अन्य सेवा द्वारा संसाधित किया जाता है - जैसे कुछ प्रकार की टेम्पल सिस्टम। यहां, सर्वर संसाधन के अस्तित्व के बारे में कोई दावा नहीं कर सकता है क्योंकि उसे इसके बारे में कुछ भी नहीं पता है (जब तक कि सेवा को संभालने वाले द्वारा नहीं बताया गया है)।
सेवा से किसी भी प्रतिक्रिया के बिना स्पष्ट रूप से एक अलग व्यवहार की आवश्यकता होती है, HTTP सर्वर केवल 3 चीजें कह सकता है:
503 यदि अनुरोध को संभालने वाली सेवा नहीं चल रही है या प्रतिक्रिया नहीं दे रही है;200 अन्यथा HTTP सर्वर वास्तव में अनुरोध को पूरा कर सकता है - कोई फर्क नहीं पड़ता कि सेवा बाद में क्या कहेगी;400या 404यह इंगित करने के लिए कि ऐसी कोई सेवा नहीं है (जैसा कि "मौजूद लेकिन ऑफ़लाइन" के विपरीत) और कुछ नहीं मिला।
2
प्रश्न पर वापस जाने के लिए: मुझे लगता है कि सबसे साफ तरीका यह होगा कि पहले से बताए गए स्थान के अलावा किसी अन्य पर किसी भी प्रतिक्रिया कोड का उपयोग न करें। यदि सेवा मौजूद है और प्रतिक्रिया दे रही है, तो एचटीटीपी कोड 200 होना चाहिए। प्रतिक्रिया में वह स्थिति होनी चाहिए जिसमें सेवा अलग हेडर में वापस आए - यहाँ, सेवा कह सकती है
REST:EMPTYजैसे अगर यह sth के लिए खोज करने के लिए कहा गया था। और वह शोध खाली लौटा;REST:NOT FOUNDअगर यह विशेष रूप से sth के लिए कहा गया था। "आईडी-लाइक" - कि एक फ़ाइल का नाम या आईडी या प्रविष्टि नंबर 24, आदि द्वारा एक संसाधन - और वह विशिष्ट संसाधन नहीं मिला (आमतौर पर, एक विशिष्ट संसाधन का अनुरोध किया गया था और नहीं मिला);REST:INVALID यदि अनुरोध के किसी भी भाग को भेजा गया था तो सेवा द्वारा मान्यता प्राप्त नहीं है।
(ध्यान दें कि मैंने इन्हें "REST:" के साथ उपसर्ग किया था, इस तथ्य को चिह्नित करने के लिए कि इनमें HTTP मान कोड के समान मान या शब्द हो सकते हैं, वे sth हैं। पूरी तरह से अलग हैं)
3
आइए ऊपर दिए गए URL पर वापस जाएं और केस B का निरीक्षण करें जहां सेवा HTTP सर्वर को इंगित करती है कि वह इस अनुरोध को स्वयं नहीं संभालता है, लेकिन इसे पास करता है SERVICE। HTTP केवल यह बताती है कि इसे किसके द्वारा वापस दिया गया है SERVICE, यह उस return/testहिस्से के बारे में कुछ भी नहीं जानता है जो इसके द्वारा नियंत्रित किया गया हैSERVICE । यदि वह सेवा चल रही है, तो HTTP को वापस लौटना चाहिए 200क्योंकि यह वास्तव में अनुरोध को संभालने के लिए कुछ मिला है ।
स्थिति SERVICE(और जैसा कि ऊपर कहा गया है, एक अलग हेडर में देखना चाहेंगे) इस बात पर निर्भर करता है कि वास्तव में क्या कार्रवाई अपेक्षित है:
- यदि
return/testकोई विशिष्ट संसाधन मांगता है: यदि यह मौजूद है, तो इसे एक स्थिति के साथ लौटाएं REST:FOUND; यदि वह संसाधन मौजूद नहीं है, तो वापस लौटें REST:NOT FOUND; REST:GONEयदि हम यह जानते हैं कि यह एक बार अस्तित्व में है और वापस नहीं लौटेगा, और REST:MOVEDयदि हम जानते हैं कि यह हॉलीवुड चला गया है , तो इसे वापस लौटने के लिए बढ़ाया जा सकता है
- यदि
return/testखोज या फ़िल्टर-जैसा ऑपरेशन माना जाता है: यदि परिणाम सेट खाली है, तो अनुरोध किए गए प्रकार और स्थिति में खाली सेट लौटाएं REST:EMPTY; अनुरोध के प्रकार और परिणामों में परिणाम का एक सेटREST:SUCCESS
- यदि
return/testइसके द्वारा पुनरावर्ती ऑपरेशन नहीं किया जाता है SERVICE: REST:ERRORयदि यह पूरी तरह से गलत है (जैसे एक टाइपो retrun/test), याREST:NOT IMPLEMENTED में इसके लिए योजना बनाई है ।
4
दो अलग-अलग चीजों को मिलाने की तुलना में यह अंतर बहुत साफ है। यह डिबगिंग को आसान बना देगा और प्रसंस्करण को थोड़ा और अधिक जटिल बना देगा, यदि बिल्कुल भी।
- यदि कोई HTTP 404 वापस आ जाता है, तो सर्वर मुझे बताता है, "मुझे कुछ पता नहीं है कि आप किस बारे में बात कर रहे हैं"। हालांकि मेरे अनुरोध का REST भाग स्पष्ट रूप से ठीक हो सकता है, मुझे सभी गलत स्थानों में par'Mach की तलाश है।
- दूसरी ओर, HTTP 200 और REST: ERR मुझे बताता है कि मुझे सेवा मिल गई है लेकिन सेवा के लिए मेरे अनुरोध में कुछ गलत है।
- HTTP 200 और REST: EMPTY से, मुझे पता है कि मैंने कुछ भी गलत नहीं किया - सही सर्वर, सर्वर को सेवा मिली, सेवा के लिए सही अनुरोध - लेकिन खोज परिणाम रिक्त है।
सारांश
समस्या और चर्चा इस तथ्य से उत्पन्न होती है कि HTTP प्रतिक्रिया कोड का उपयोग उस सेवा की स्थिति को बताने के लिए किया जा रहा है जिसके परिणाम HTTP द्वारा दिए गए हैं, या sth को निरूपित करने के लिए। यह स्वयं HTTP सर्वर के दायरे में नहीं है। इस विसंगति के कारण, इस सवाल का जवाब नहीं दिया जा सकता है और सभी राय बहुत चर्चा के अधीन हैं।
एक सेवा द्वारा संसाधित अनुरोध का राज्य और HTTP सर्वर प्रतिक्रिया नहीं (RFC 6919) HTTP प्रतिक्रिया कोड द्वारा नहीं दी जानी चाहिए। HTTP कोड SHOULD (RFC 2119) में केवल वह जानकारी होती है जो HTTP सर्वर अपने स्वयं के दायरे से दे सकता है: अर्थात्, सेवा अनुरोध को संसाधित करने के लिए मिली थी या नहीं।
इसके बजाय, एक उपभोक्ता को सेवा के लिए अनुरोध की स्थिति के बारे में बताने के लिए एक अलग तरीके का उपयोग किया जाना चाहिए जो वास्तव में अनुरोध को संसाधित कर रहा है। मेरा प्रस्ताव एक विशिष्ट हेडर के माध्यम से ऐसा करने का है। आदर्श रूप से, हेडर का नाम और इसकी सामग्री दोनों एक मानक का पालन करते हैं जो उपभोक्ताओं के लिए थिसस प्रतिक्रियाओं के साथ काम करना आसान बनाता है।
