आंशिक सफल अनुरोध के लिए HTTP स्थिति कोड


115

मेरे पास एक एप्लिकेशन है जो उपयोगकर्ताओं को संदेश भेजता है। पोस्ट अनुरोध में एक XML स्ट्रिंग को स्थानांतरित किया जाता है जिसमें सभी उपयोगकर्ता शामिल होते हैं जिन्हें उस विशेष संदेश को प्राप्त करना चाहिए। यदि सूची में मौजूद कोई भी उपयोगकर्ता मौजूद नहीं है, तो मैं लापता उपयोगकर्ताओं की सूची ग्राहक को आगे के मूल्यांकन के लिए वापस दे देता हूं।

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

यदि सूची में लापता उपयोगकर्ताओं को शामिल करने की अनुमति नहीं थी, तो समस्या से बचा जाएगा। तब भेजने का प्रयास सिर्फ 4xx त्रुटि प्राप्त करेगा। लेकिन इस तरह से एपीआई बनाने का कोई मतलब नहीं है। दूसरी ओर मैं त्रुटि स्थिति पर विशुद्ध रूप से आवेदन विशिष्ट होने पर विचार कर सकता था। लेकिन सिर्फ 200 भेजना ठीक नहीं लगता। और ग्राहक को संकेत देने के लिए अच्छा होगा जब त्रुटि प्रतिक्रिया में गहराई से देखना होगा। उन उपयोगकर्ताओं को संदेश भेजने से बचने के लिए उदा

जवाबों:


66

मैं एक बहुत ही इसी तरह की समस्या से निपट चुका हूं। इस मामले में, मैं एक लौट आया

207 मल्टी-स्टेटस

अब, यह सख्त HTTP नहीं है, यह WebDAV एक्सटेंशन का हिस्सा है, इसलिए यदि आपका क्लाइंट पर भी नियंत्रण नहीं है, तो यह आपके लिए अच्छा नहीं है। यदि आप ऐसा करते हैं, तो आप ऐसा कुछ कर सकते हैं:

   <?xml version="1.0" encoding="utf-8" ?>
   <D:multistatus xmlns:D='DAV:'>
     <D:response>
       <D:user>user-123</D:user>
       <D:status>success</D:status>
     </D:response>
     <D:response>
       <D:user>user-789</D:user>
       <D:status>failure</D:status>
     </D:response>
   </D:multistatus>

लेकिन फिर से, यह एक HTTP एक्सटेंशन है, और आपको क्लाइंट का नियंत्रण भी होना चाहिए।


3
मैंने इसका उपयोग करने के बारे में सोचा लेकिन मैं इसके साथ बहुत सहज नहीं था। धन्यवाद!
नॉर्बर्ट हार्टल

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

मै समझता हुँ। मैं सिर्फ एक अतिरिक्त स्तर की स्थिति से बचने की कोशिश कर रहा हूं (जो कि अच्छा IMHO नहीं है)। मेरा अधिकांश कोड HTTP वाले के साथ काम करता है। और मुझे लगता है कि मेरा वर्णित उपयोग मामला बिना ठीक होगा।
नोर्बर्ट हार्टल

आप हमेशा एक निकाय को वापस भेज सकते हैं - एक JSON प्रतिक्रिया के साथ 200 भेज सकते हैं या जो कुछ भी आप यह निर्धारित करना चाहते हैं कि कौन से सफल थे।
काइलर

हाँ मैं जानता हूँ। लेकिन अगर आप एक शरीर वापस करते हैं तो आपको इसे पार्स करने की आवश्यकता है। और उस क्षण में आप एप्लिकेशन लॉजिक हैंडलिंग की दूसरी परत पेश करते हैं। यह जटिलता बढ़ाता है और आपको इसे करने के लिए एक अच्छे कारण की आवश्यकता होती है।
नॉर्बर्ट हार्टल

65

मुझे एक ही समस्या है, और मैंने दो अलग-अलग समाधानों का उपयोग करके समाप्त किया है:

  • HTTP रिटर्न कोड 202: Accepted, यह दर्शाता है कि अनुरोध ठीक था, लेकिन इसकी कोई गारंटी नहीं है कि सब कुछ वास्तव में जैसा कि होना चाहिए था।
  • 200प्रतिक्रिया में एक सामान्य लौटें , लेकिन क्या प्रतिक्रिया निकाय में पैन नहीं किया है की एक सूची शामिल करें।

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


5
क्या 202 कतार की तरह कुछ का जिक्र नहीं कर रहा है?
19

6
जी हां, @ साइनेथेटिक। सबसे हालिया HTTP 1.1 कल्पना से, "(...) प्रसंस्करण के लिए अनुरोध स्वीकार कर लिया गया है, लेकिन प्रसंस्करण पूरा नहीं हुआ है"। इसलिए, आंशिक सफलता के लिए, 202 उपयुक्त नहीं है।
Huercio

-4

206 आंशिक सामग्री का उपयोग करने के बारे में क्या। मुझे पता है कि 206 सीमाओं के बारे में अधिक है, लेकिन क्या होगा अगर यह आंशिक रूप से सफलतापूर्वक अनुरोध का संकेत दे सकता है?


एमडीएन निम्नानुसार है: "HTTP 206 आंशिक सामग्री सफलता की स्थिति प्रतिक्रिया कोड इंगित करता है कि अनुरोध सफल हुआ है और इसमें डेटा की अनुरोधित श्रेणियां शामिल हैं, जैसा कि अनुरोध के श्रेणी शीर्षलेख में वर्णित है।" जहाँ तक मैं समझता हूँ, २०६ आंशिक सामग्री कड़ाई से सामग्री सीमा के अनुरोध के लिए है।
जुब

-14

हाइपरटेक्स्ट ट्रांसफर प्रोटोकॉल चीजों के ट्रांसमिशन पक्ष से संबंधित है। इसमें एप्लिकेशन स्तर की त्रुटियों से निपटने के लिए त्रुटि कोड नहीं हैं।

200 लौटना यहाँ सही काम है। जहाँ तक HTTP का संबंध है अनुरोध ठीक से प्राप्त हुआ, ठीक से संभाला गया और आप प्रतिक्रिया वापस भेज रहे हैं। तो, HTTP स्तर पर सब कुछ ठीक है। Http के शीर्ष पर चलने वाले एप्लिकेशन से संबंधित कोई भी त्रुटि या चेतावनी प्रतिक्रिया के अंदर होनी चाहिए। ऐसा करने से कुछ खराब मुद्दों को भी रोका जा सकता है जो आप प्रॉक्सी सर्वरों के साथ चला सकते हैं जो कुछ प्रतिक्रियाओं को आपके द्वारा अपेक्षित तरीके से नहीं संभाल सकते हैं।


18
HTTP एक एप्लिकेशन स्तर प्रोटोकॉल है। आप इसे केवल परिवहन और आवेदन स्तर पर नहीं डाल सकते। अगर आप OSI के बारे में सोचते हैं तो HTTP 5-7 लेयर्स पर है। HTTP कुछ अलग है। अधिकांश हेडर और रिटर्न कोड वास्तव में एप्लिकेशन विशिष्ट हैं। कोड सिर्फ HTTP प्रोटोकॉल संस्थाओं में दी गई जानकारी पर निर्भर करते हैं न कि कस्टम एप्लिकेशन फॉर्मेट की चीजों पर। 200 के बारे में मैं यह कहूंगा कि आपकी परिभाषा विशुद्ध रूप से गलत है, अगर इसे क्रियाओं पर लागू किया जाता है, तो POST नहीं। लेकिन POST खेल को थोड़ा बदल देता है और इस संदर्भ में आपकी धारणा "ठीक से संभाला" निश्चित नहीं है, या तो
नॉर्बर्ट हार्टल

स्ट्रिकली बोलने वाला OSI HTTP को एक एप्लीकेशन लेवल प्रोटोकॉल मानता है और जब 'सामान्य' वेबसर्वर से बात करता है तो यह सच है। लेकिन आपके मामले में आप अपना खुद का प्रोटोकॉल HTTP के ऊपर चला रहे हैं, जैसे इन दिनों बहुत सारे एप्लिकेशन करते हैं। उस प्रकार के उपयोग में HTTP बस परिवहन प्रदान करता है। (आपका एप्लिकेशन उपयोगकर्ताओं को संदेश भेज रहा है, हाइपरटेक्स्ट को स्थानांतरित नहीं कर रहा है ...)
AVee

2
केवल स्पष्ट करने के लिए। REST तरीके से HTTP संसाधन केंद्रित है। इस संदर्भ में 200 का मतलब 3xx के बजाय पहचान (आपके द्वारा निर्दिष्ट संसाधन) है जो पहचान की दिशा में इंगित करता है। POST के उपयोग से संसाधन URI को एक प्रसंस्करण URI में बदल देता है और इससे निपटने में त्रुटि कोड की आवश्यकता होती है। संदर्भ थोड़ा बदल जाता है और चीजों की रक्षा थोड़ी धुंधली हो जाती है या कम से कम समझने में मुश्किल होती है
नॉर्बर्ट हार्टल

1
संदर्भ बदलाव का यह भी मतलब है कि कोई उपयुक्त त्रुटि कोड नहीं हैं, क्योंकि प्रोटोकॉल को कभी भी उस संदर्भ को ध्यान में रखकर डिजाइन नहीं किया गया था;; मुझे भी लगता है कि आपको त्रुटि कोड का उपयोग करने में सावधानी बरतनी चाहिए क्योंकि प्रॉक्सी सर्वर उनके साथ आपकी प्रतिक्रिया को बदलने के लिए दौड़ते हैं कस्टम त्रुटि पृष्ठ, यह एक वास्तविक PITA हो सकता है।
एवी डेसी

1
वैसे भी, मेरे सवाल का जवाब देने के लिए धन्यवाद। मुझे पता चला कि स्टैकओवरफ्लो खराब चैट क्लाइंट है :)
नॉर्बर्ट हार्टल
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.