अद्यतन और हटाने के लिए HTTP स्थिति कोड?

Question

मुझे किस स्थिति के लिए UPDATE( PUT) और DELETE(जैसे उत्पाद सफलतापूर्वक अपडेट किया गया) कोड सेट करना चाहिए ?

Answer 1

एक के लिए PUT अनुरोध: HTTP 200 या HTTP 204 मतलब चाहिए "संसाधन सफलतापूर्वक अपडेट किया गया"।

एक के लिए DELETE अनुरोध: HTTP 200 या HTTP 204 मतलब चाहिए "संसाधन सफलतापूर्वक नष्ट कर दिया"। HTTP 202 को भी लौटाया जा सकता है जिसका अर्थ होगा कि सर्वर द्वारा निर्देश को स्वीकार कर लिया गया था और "संसाधन को हटाने के लिए चिह्नित किया गया था"।

डाल

यदि किसी मौजूदा संसाधन को संशोधित किया जाता है, तो 200 (ओके) या 204 (कोई सामग्री) प्रतिक्रिया कोड> SHOULD को अनुरोध के सफल समापन को इंगित करने के लिए भेजा जाना चाहिए।

हटाएँ

एक सफल प्रतिक्रिया 200 होना चाहिए (ठीक है) यदि प्रतिक्रिया में स्थिति का वर्णन करने वाली एक इकाई शामिल है, 202 (स्वीकृत) यदि कार्रवाई अभी तक लागू नहीं हुई है, या 204 (कोई सामग्री नहीं) यदि कार्रवाई अधिनियमित की गई है, लेकिन प्रतिक्रिया में शामिल नहीं है एक इकाई।

स्रोत: W3.org: HTTP / 1.1 विधि परिभाषाएँ

HTTP 200 ओके: सफल HTTP अनुरोधों के लिए मानक प्रतिक्रिया। वास्तविक प्रतिक्रिया उपयोग की गई अनुरोध विधि पर निर्भर करेगी।

HTTP 204 कोई सामग्री नहीं: सर्वर ने अनुरोध को सफलतापूर्वक संसाधित किया, लेकिन कोई भी सामग्री वापस नहीं कर रहा है

स्रोत: HTTP स्टेटस कोड्स की सूची: 2xx सफलता

Comments

बहुत उपयोगी पोस्ट! हालाँकि मैं सोच रहा हूँ कि HTTP स्टेटस कोड क्या होना चाहिए यह क्लाइंट द्वारा भेजा गया अनुरोध वैध है (डिलीट मायसाइट / यूनिट / 123 ) और डिलीट करने की इकाई मौजूद नहीं है।

— मार्टिन

@Martin: उस मामले में, सेवा को कोई HTTP चाहिए 404. सच पूछिये तो, एक को हटाने या मौजूद नहीं है वह यह है कि एक संसाधन के लिए एक GET अनुरोध नहीं एक "वैध" अनुरोध - अर्थात्। क्लाइंट को उस अनुरोध को फिर से प्रयास नहीं करना चाहिए क्योंकि यह कभी सफल नहीं होगा ... HTTP प्रोटोकॉल 2 श्रेणियों की समस्याओं को परिभाषित करता है - वे 4xx स्थिति कोड के साथ, जहां ग्राहक को पुनः प्रयास करने से पहले अनुरोध को संशोधित करना होगा, और 5xx स्थिति वाले लोग कोड, जो इंगित करता है कि सेवा मुसीबत में चली गई और ग्राहक को इसे बदलने के बिना उसी सटीक अनुरोध को पुनः प्राप्त / करना चाहिए।

— डैनियल वेसलो

@JeffMartin उपयोगकर्ता के दृष्टिकोण से ऐसा हो सकता है, लेकिन जहां तक ​​सर्वर का सवाल है, अगर संसाधन मौजूद नहीं है, तो सर्वर को 404 वापस करना चाहिए।

— Randolpho

@ रैंडोल्फो, Idempotence सभी एक ही परिणाम प्राप्त करने के बारे में है कि क्या आप एक बार या कई बार किसी ऑपरेशन का आह्वान करते हैं। ग्राहक आपसे यह सुनिश्चित करने के लिए कह रहा है कि संसाधन हटा दिया गया है। 404 लौटाने से क्या फायदा? इसे किसी भी तरह से जानने की आवश्यकता क्यों है? अब क्लाइंट लॉजिक को एक के बजाय दो अलग-अलग प्रतिक्रिया कोड संभालना होगा।

— गिल्ली

@ गिल्ली: शायद विकी बेहतर तरीके

— रैंडोल्फो

Answer 2

संक्षिप्त उत्तर: PUT और DELETE दोनों के लिए, आपको 200 (OK) या 204 (कोई सामग्री नहीं) भेजनी चाहिए।

लंबे उत्तर: यहाँ एक पूर्ण निर्णय आरेख (क्लिक करें बढ़ाना) है।

स्रोत: https://github.com/for-GET/http-decision-diagram

Comments

आरेख अद्भुत है। क्या प्रिंट आउट के लिए उच्च रिज़ॉल्यूशन संस्करण है?

— KiKi

मौजूदा संसाधन के POST के संदर्भ में, एक अन्य SO चर्चा ( stackoverflow.com/questions/3825990/… ) सामग्री को जोड़ने के बजाय 409 संघर्ष या 302 मिला भेजने का सुझाव देती है।

— कोपरपॉ

मैं उत्सुक हूं कि यदि डिलीट होने के बाद 204 और 200 की प्रतिक्रिया को उलट दिया जाए, और यदि वे सही हैं, तो क्यों? हटाए गए? -> प्रतिक्रिया में एक इकाई शामिल है? -> हाँ -> 204 कोई सामग्री नहीं; नहीं -> 200 ठीक

— मट

छवि का अपडेट किया गया संस्करण यहां है: raw.github.com/for-GET/http-decision-diagram/master/httpdd.png

— zaius

यह पाट को याद कर रहा है।

— doremi

Answer 3

यहाँ कुछ युक्तियाँ हैं:

हटाएँ

• 200 (यदि आप प्रतिक्रिया में कुछ अतिरिक्त डेटा भेजना चाहते हैं) या 204 (अनुशंसित)।

• 202 हटाए गए ऑपरेशन अभी तक प्रतिबद्ध नहीं हैं।

• यदि डिलीट करने के लिए कुछ नहीं है, तो 204 या 404 का उपयोग करें (DELETE ऑपरेशन, बेरोजगार है, पहले से हटाए गए आइटम को हटा दें ऑपरेशन सफल है , इसलिए आप 204 को वापस कर सकते हैं , लेकिन यह सच है कि idempotent जरूरी नहीं है कि समान प्रतिक्रिया हो)

अन्य त्रुटियां:

• 400 खराब अनुरोध (विकृत सिंटैक्स या एक खराब क्वेरी अजीब लेकिन संभव है)।
• 401 अनधिकृत प्रमाणीकरण विफलता
• 403 निषिद्ध : प्राधिकरण की विफलता या अमान्य एप्लिकेशन आईडी।
• 405 अनुमति नहीं है । ज़रूर।
• 409 संसाधन संघर्ष जटिल प्रणालियों में संभव हो सकता है।
• और त्रुटियों के मामले में 501 , 502 ।

डाल

यदि आप किसी संग्रह का एक तत्व अपडेट कर रहे हैं

• 200/204 ऊपर दिए गए DELETE के समान कारणों के साथ।
• 202 यदि ऑपरेशन अभी तक शुरू नहीं किया गया है।

संदर्भित तत्व मौजूद नहीं है:

• PUT 201 हो सकता है (यदि आपने तत्व बनाया है क्योंकि वह आपका व्यवहार है)

• 404 यदि आप PUT के माध्यम से तत्व नहीं बनाना चाहते हैं।

• 400 बुरा अनुरोध (विकृत सिंटैक्स या DELETE के मामले की तुलना में अधिक सामान्य प्रश्न)।

• 401 अनधिकृत
• 403 निषिद्ध : प्रमाणीकरण विफलता या अमान्य एप्लिकेशन आईडी।
• 405 अनुमति नहीं है । ज़रूर।
• 409 संसाधन संघर्ष जटिल प्रणालियों में संभव हो सकता है, जैसा कि DELETE में है।
• 422 असंगत इकाई यह "खराब अनुरोध" (जैसे विकृत XML / JSON) और अमान्य फ़ील्ड मानों के बीच अंतर करने में मदद करता है
• और त्रुटियों के मामले में 501 , 502 ।

Comments

यह उत्तर लगभग पूरी तरह से दो बड़े उद्धरणों से बना है, लेकिन कोई विशेषता नहीं है। आप कहाँ से उद्धृत कर रहे हैं?

— क्वेंटिन

यदि राज्य को प्रभावी ढंग से नहीं बदला जाता है, तो क्या 204 को PUT अनुरोध के लिए वापस लौटने की उचित स्थिति है? उदाहरण के लिए, आप किसी उपयोगकर्ता को निष्क्रिय करने के लिए कहते हैं लेकिन उपयोगकर्ता पहले से ही निष्क्रिय है।

— 18 Г И О И О

PUT रिक्वेस्ट idempotent है, इसलिए आप 204 लौटा सकते हैं, क्योंकि सिस्टम में ऑब्जेक्ट बदल गया है। PUT PCHCH नहीं है, इसलिए आप निश्चित नहीं हैं कि आप किस क्षेत्र को बदलना चाहते हैं। आप वापस भेज सकते हैं एक 501 - 502, अपने डिजाइन जानना चाहते हैं कि वस्तु थी की जरूरत है वास्तव में अनुरोध में वस्तु के रूप में ही है, लेकिन ... मैं इसे की तरह वास्तव में नहीं है .. मैं 204 पसंद करते हैं या, यदि आप चाहते हैं अधिक फ़ील्ड्स को बदले बिना, एक उपयोगकर्ता को निष्क्रिय करें, शायद आप PATCH का उपयोग कर सकते हैं।

— अल्फांसो टिएंडा

मैं HTTP 422 Unprocessable Entity जोड़ूंगा। यह "खराब अनुरोध" (जैसे विकृत XML / JSON) और अमान्य फ़ील्ड मानों के बीच अंतर करने में मदद करता है।

— vdboor

Answer 4

RFC 2616 बताता है कि किन स्टेटस कोड का उपयोग करना है ।

और नहीं, यह हमेशा 200 नहीं होता है।

Answer 5

200 और 204 के अलावा, 205 (रीसेट सामग्री) एक वैध प्रतिक्रिया हो सकती है।

सर्वर ने अनुरोध पूरा कर लिया है और उपयोगकर्ता एजेंट SHOULD दस्तावेज़ दृश्य को रीसेट कर देता है जिसके कारण अनुरोध भेजा जा रहा है ... [जैसे] इनपुट दिए जाने के तरीके को साफ़ करना।

Answer 6

चूँकि प्रश्न यह बताता है कि DELETE को " 200 बनाम 204 वापस करना चाहिए" यह विचार करने योग्य है कि कुछ लोग लिंक के साथ एक इकाई को वापस करने की सलाह देते हैं, इसलिए वरीयता 200 के लिए है ।

"204 (कोई सामग्री) वापस करने के बजाय, एपीआई सहायक होना चाहिए और जाने के लिए स्थानों का सुझाव देना चाहिए। इस उदाहरण में मुझे लगता है कि प्रदान करने के लिए एक स्पष्ट लिंक" 'कहीं है / -कंटेनर /' (माइनस 'संसाधन') "- कंटेनर जिसमें से ग्राहक ने एक संसाधन को हटा दिया है। शायद ग्राहक अधिक संसाधनों को हटाना चाहता है, इसलिए यह एक सहायक लिंक होगा। "

http://blog.ploeh.dk/2013/04/30/rest-lesson-learned-avoid-204-responses/

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

व्यक्तिगत रूप से मैं यह नहीं कहूंगा कि 204 गलत है (न ही लेखक कहता है; वह कहता है "कष्टप्रद") क्योंकि क्लाइंट की तरफ से अच्छी कैशिंग के कई फायदे हैं। सबसे अच्छा तरीका है।

Answer 7

यहां कुछ स्टेटस कोड दिए गए हैं, जिन्हें आपको अपने ज्ञान के लिए जानना चाहिए।

1XX सूचना प्रतिक्रियाएं

• 100 जारी रखें
• 101 स्विचिंग प्रोटोकॉल
• 102 प्रसंस्करण
• 103 प्रारंभिक संकेत

2XX सफलता

• 200 ठीक है
• 201 बनाया गया
• 202 स्वीकार किए जाते हैं
• 203 गैर-आधिकारिक सूचना
• 204 कोई सामग्री नहीं
• 205 रीसेट सामग्री
• 206 आंशिक सामग्री
• 207 मल्टी-स्टेटस
• 208 पहले से ही रिपोर्ट की गई
• 226 IM का उपयोग किया

3XX पुनर्निर्देशन

• 300 एकाधिक विकल्प
• 301 स्थायी रूप से चले गए
• 302 मिला
• 303 अन्य देखें
• 304 संशोधित नहीं है
• 305 प्रॉक्सी का उपयोग करें
• 306 स्विच प्रॉक्सी
• 307 अस्थाई पुनर्निर्देश
• 308 स्थायी पुनर्निर्देश

4XX क्लाइंट त्रुटियों

• 400 खराब अनुरोध
• 401 अनधिकृत
• 402 भुगतान आवश्यक है
• 403 निषिद्ध
• 404 नहीं मिला
• 405 विधि अनुमति नहीं है
• 406 स्वीकार्य नहीं है
• 407 प्रॉक्सी प्रमाणीकरण आवश्यक
• 408 अनुरोध टाइमआउट
• 409 संघर्ष
• 410 गॉन
• 411 लंबाई आवश्यक है
• 412 पूर्वधारणा विफल
• 413 पेलोड बहुत बड़ा
• 414 यूआरआई बहुत लंबा
• 415 असमर्थित मीडिया प्रकार
• 416 रेंज संतोषजनक नहीं है
• 417 उम्मीद असफल रही
• 418 मैं एक चायदानी हूँ
• 420 विधि विफलता
• 421 गलत अनुरोधित
• 422 असंसाधित इकाई
• 423 बंद
• 424 असफलता निर्भरता
• 426 अपग्रेड आवश्यक है
• 428 पूर्व शर्त आवश्यक
• 429 बहुत सारे अनुरोध
• 431 अनुरोध हैडर फ़ील्ड बहुत बड़ा है
• 451 कानूनी कारणों के लिए अनुपलब्ध

5XX सर्वर त्रुटियाँ

• 500 आंतरिक सर्वर त्रुटि
• 501 लागू नहीं किया गया
• 502 खराब गेटवे
• 503 सेवा अनुपलब्ध
• 504 गेटवे टाइमआउट
• 505 Http संस्करण समर्थित नहीं है
• 506 रोगी भी बातचीत करते हैं
• 507 अपर्याप्त संग्रहण
• 508 लूप का पता लगाया
• 510 विस्तारित नहीं
• 511 नेटवर्क प्रमाणीकरण आवश्यक

Answer 8

जून 2014 में RFC7231 ने RFC2616 का पालन किया। यदि आप HTTP पर REST कर रहे हैं तो RFC7231 वर्णन करता है कि GET, PUT, POST और DELETE से वास्तव में क्या व्यवहार अपेक्षित है

Answer 9

जब कोई संसाधन संशोधित किया जाता है, तो प्रतिक्रिया कोड 200 ("ओके") होना चाहिए । यदि संसाधन स्थिति एक तरह से बदल जाती है जो URI को संसाधन में बदल देती है (उदाहरण के लिए, एक उपयोगकर्ता खाता नाम बदला गया है), तो प्रतिक्रिया कोड 301 है ("स्थायी रूप से स्थानांतरित") और स्थान शीर्षलेख को नया URI प्रदान करना चाहिए।

जब कोई ऑब्जेक्ट हटा दिया जाता है, तो प्रतिक्रिया कोड 200 ("ओके") होना चाहिए।

अधिक जानकारी के लिए नीचे दिए गए लिंक का पालन करें - बाकी के लिए स्थिति कोड