2012-10-22 35 views
14

मान लें कि मेरे पास संसाधन है (उदा: /api/shipments/100) जो HTTP DELETE विधि का समर्थन करता है। जैसा कि आप यूआरआई से ही समझ सकते हैं, अगर इस यूआरआई के खिलाफ एक अनुरोध अनुरोध किया गया है, तो यह संसाधन हटा दिया जाएगा।किसी HTTP स्थिति कोड को वापस करने के लिए जब DELETE ऑपरेशन को किसी विशेष कारण के लिए अनुमति नहीं दी जाती है

मेरे वर्तमान परिदृश्य में, हटाने का अनुरोध केवल सफलतापूर्वक किया जा सकता है अगर एक निश्चित शर्त के रूप में नीचे पूरा किया जाता है: शिपमेंट राज्य InTransit पर सेट नहीं है

  • हैं या वितरित किया गया।

यदि उस यूआरआई के खिलाफ एक डेली अनुरोध है और उपरोक्त शर्त पूरी नहीं हुई है, तो उस स्थिति में वापस आने के लिए कौन सी HTTP स्थिति कोड अधिक उचित होगा? मैं नीचे लोगों के बारे में सोचा है, लेकिन तय नहीं कर सकता है जो एक और अर्थ है:

  • 405 पद्धति की अनुमति नहीं
  • 403 निषिद्ध
  • 409 विरोधाभास

उत्तर

15

मैं 409: Conflict साथ जाना होगा, क्योंकि आपके पास संसाधन संसाधन का उल्लंघन है।

405: Method Not Allowed भी काम करेगा। यदि आप 405 का उपयोग करना चाहते हैं, तो आपको समर्थित विधियों को इंगित करने के लिए Allow शीर्षलेख भेजना होगा, और समर्थित विधियां संसाधन के राज्य पर निर्भर रहती हैं। मेरी राय में, यह प्रतिक्रिया कोड केवल पढ़ने के लिए संसाधनों के लिए उपयुक्त है, संसाधन जिन्हें हटाया नहीं जा सकता है आदि। लेकिन इस पोस्ट पर Darrel की टिप्पणियां मान्य हैं। कल्पना संदिग्ध है:

अनुरोध-रेखा में निर्दिष्ट विधि को अनुरोध-यूआरआई द्वारा पहचाने जाने वाले संसाधन की अनुमति नहीं है। प्रतिक्रिया में अनुरोधित संसाधन के लिए वैध विधियों की सूची वाले हेडर को अनुमति दें।

किसी भी मामले में, आपको त्रुटि के स्रोत को समझने के लिए ग्राहक के लिए प्रतिक्रिया निकाय में जानकारी प्रदान करनी चाहिए।

403: Forbidden और यानी अगर आपको लगता है कि संसाधन को हटाने के लिए व्यवस्थापक बनना है, तो आप संसाधन संशोधित करने के लिए उचित विशेषाधिकार नहीं हैं जब इस्तेमाल किया जाना चाहिए आप:


अन्य दो विधियों का उल्लेख के बारे में

'नहीं हैं।

412: Precondition Failed अधिकतर सशर्त अनुरोधों के लिए उपयोग किया जाता है जहां पूर्व शर्त अनुरोध हेडर में स्पष्ट रूप से निर्दिष्ट की जाती हैं। उदाहरण के लिए, आपके पास सशर्त PUT अनुरोध हो सकते हैं जिन्हें केवल If-Match शीर्षलेख मान्य होने पर ही किया जाना चाहिए। आप अनुरोध हेडर में कुछ भी निर्दिष्ट नहीं करते हैं, मैं अभी भी निर्णय लेना होगा 409 412. अधिक यहाँ 412 के लिए कल्पना है:

पूर्व शर्त एक या अनुरोध हेडर क्षेत्रों के अधिक में दी गई गलत पर मूल्यांकन किया जाता जब यह सर्वर पर परीक्षण किया गया था।यह प्रतिक्रिया कोड क्लाइंट को वर्तमान संसाधन मेटाफ़ॉर्मेशन (हेडर फ़ील्ड डेटा) पर पूर्व शर्त लगाने की अनुमति देता है और इस प्रकार अनुरोध किए गए विधि को किसी अन्य उद्देश्य के अलावा संसाधन पर लागू होने से रोकता है।

+0

के लिए इस देखते हैं? आप कैसे कह सकते हैं कि संसाधन कभी भी किसी विशेष विधि का समर्थन नहीं करेगा? मुझे समय के साथ बदल रहे समर्थित तरीकों के साथ कोई समस्या नहीं दिखाई दे रही है। –

+0

कृपया मेरा संपादन देखें। –

+0

इसके अलावा, यदि आप हेडर को अनुमति देने की परिभाषा को देखते हैं, तो इसमें टिप्पणी शामिल है 'अनुमत विधियों का वास्तविक सेट प्रत्येक अनुरोध के समय मूल सर्वर द्वारा परिभाषित किया गया है' यह मुझे बताता है कि विधियों का सेट "अनुमत" बदलने की उम्मीद है, और 405 वर्तमान स्थिति को प्रतिबिंबित कर रहा है। http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-18#section-9.1 –

1

मैं 412 का उपयोग करूंगा: पूर्व शर्त विफल।

कृपया आप 405 के खिलाफ अपने तर्क के लिए एक संदर्भ है HTTP स्थिति कोड

Web Status Codes

+0

लेकिन यह कहता है "** अनुरोध-हेडर फ़ील्ड में से एक या अधिक में दी गई पूर्व शर्त ** सर्वर पर परीक्षण किए जाने पर गलत होने का मूल्यांकन किया गया" जो मेरी राय में अर्थपूर्ण नहीं होगा। – tugberk

+0

मैं सहमत हूं, कृपया मेरा अपडेट देखें। –