जब संसाधन पहले से मौजूद हों तो POST के लिए HTTP प्रतिक्रिया कोड

842

मैं एक सर्वर बना रहा हूं जो क्लाइंट को ऑब्जेक्ट स्टोर करने की अनुमति देता है। उन ऑब्जेक्ट्स को क्लाइंट साइड पर पूरी तरह से बनाया गया है, जो ऑब्जेक्ट आईडी के साथ पूरा होते हैं जो ऑब्जेक्ट के पूरे जीवनकाल के लिए स्थायी हैं।

मैंने API को परिभाषित किया है ताकि ग्राहक PUT का उपयोग करके ऑब्जेक्ट बना या संशोधित कर सकें:

PUT /objects/{id} HTTP/1.1
...

{json representation of the object}

{आईडी} ऑब्जेक्ट आईडी है, इसलिए यह अनुरोध-यूआरआई का हिस्सा है।

अब, मैं ग्राहकों को POST का उपयोग करके ऑब्जेक्ट बनाने की अनुमति देने पर भी विचार कर रहा हूं:

POST /objects/ HTTP/1.1
...

{json representation of the object, including ID}

चूंकि POST को "अपेंड" ऑपरेशन के रूप में माना जाता है, मुझे यकीन नहीं है कि वस्तु पहले से ही वहां है तो क्या करें। क्या मुझे अनुरोध को संशोधन अनुरोध के रूप में मानना चाहिए या मुझे कुछ त्रुटि कोड (जो) वापस करना चाहिए?

rest http http-status-codes

— vmj
स्रोत

5

जब तक ईमेल मौजूद रहता है जून 2016 तक एफबी blatantly 200 को सेट करता है

— ग्रीन

4

Github API 422 तब लौटाता है जब पहले से उपयोग में आने वाले नाम के साथ एक संसाधन (टीम / रेपो) बनाने की कोशिश कर रहा है

— केन

1

यह निर्भर करता है कि आप वस्तु के अस्तित्व को त्रुटि मानते हैं या नहीं। यदि आप परिशिष्ट को संसाधित करते हैं, तो 200 या 204 सबसे उपयुक्त प्रतिक्रिया कोड हैं।

— सनकैट २२

1055

मेरी भावना 409 Conflictसबसे उपयुक्त है, हालांकि, शायद ही कभी जंगली में देखा जाता है:

संसाधन की वर्तमान स्थिति के साथ विरोध के कारण अनुरोध पूरा नहीं किया जा सका। इस कोड को केवल उन स्थितियों में अनुमति दी जाती है जहां यह उम्मीद की जाती है कि उपयोगकर्ता संघर्ष को हल करने में सक्षम हो सकता है और अनुरोध को फिर से शुरू कर सकता है। प्रतिक्रिया बॉडी SHOULD में संघर्ष के स्रोत को पहचानने के लिए उपयोगकर्ता के लिए पर्याप्त जानकारी शामिल है। आदर्श रूप से, प्रतिक्रिया इकाई में समस्या को ठीक करने के लिए उपयोगकर्ता या उपयोगकर्ता एजेंट के लिए पर्याप्त जानकारी शामिल होगी; हालाँकि, यह संभव नहीं हो सकता है और इसकी आवश्यकता नहीं है।

PUT अनुरोध के जवाब में विरोध होने की सबसे अधिक संभावना है। उदाहरण के लिए, यदि संस्करण का उपयोग किया जा रहा था और PUT होने वाली इकाई में एक संसाधन में परिवर्तन शामिल थे, जो कि पहले (थर्ड-पार्टी) अनुरोध द्वारा किए गए लोगों के साथ संघर्ष करता है, तो सर्वर यह संकेत देने के लिए 409 प्रतिक्रिया का उपयोग कर सकता है कि यह अनुरोध को पूरा नहीं कर सकता है। । इस स्थिति में, प्रतिक्रिया इकाई में संभवतः दो प्रकारों के बीच अंतरों की एक सूची होगी, जो प्रतिक्रिया सामग्री-प्रकार द्वारा परिभाषित प्रारूप में होगी।

— Wrikken
स्रोत

11

400 खराब अनुरोध के लिए क्यों नहीं? मेरे लिए यह एक सत्यापन त्रुटि जैसा लगता है (आप अवैध आईडी के साथ गलत पेलोड प्रदान कर रहे हैं)।

— मैनुअल अलादाना

314

400 => "अनुरोध सर्वर द्वारा विकृत सिंटैक्स के कारण समझा नहीं जा सका" । और सर्वर पूरी तरह से समझता है, लेकिन एक संघर्ष के कारण पालन करने में असमर्थ है। केवल डेटा समस्या के अनुरोध और वाक्यविन्यास में कुछ भी गलत नहीं है। एक 400 मुझे तुरंत विश्वास दिलाता है कि मैं जिस पूरे तंत्र का उपयोग कर रहा हूं, वह त्रुटिपूर्ण है, बजाय सिर्फ आंकड़ों के।

— 19

42

@Wrikken अब सही नहीं है। HTTP 400 को RFC 7231 में बदल दिया गया था, जिसका अर्थ है कि "सर्वर किसी क्लाइंट त्रुटि के कारण होने वाली चीज़ के कारण अनुरोध को संसाधित नहीं करेगा या नहीं करेगा (उदाहरण के लिए, विकृत अनुरोध वाक्यविन्यास, अमान्य अनुरोध संदेश फ़्रेमिंग, या भ्रामक अनुरोध रूटिंग)।" मैं यह नहीं कह रहा हूं कि 400 इस मामले में सही उपयोग है लेकिन यह 400 की नई परिभाषा के साथ सही हो सकता है।

— javajavajavajavajava

19

@javajavajavavajavajava: फिर भी, डुप्लिकेट डेटा मेरे दिमाग में एक 'ग्राहक त्रुटि' नहीं है, लेकिन यह निश्चित रूप से देखने वाले की नजर में है।

— जूल

21

मैं मौजूदा / परस्पर विरोधी संसाधन की ओर इशारा करते हुए हेडर के HTTP 409साथ लौटता हूं Location।

— जिली

100

RFC 7231 के अनुसार , 303 See अन्य MAY का उपयोग किया जाना चाहिए यदि POST को संसाधित करने का परिणाम मौजूदा संसाधन के प्रतिनिधित्व के बराबर होगा ।

— nullius
स्रोत

4

मेरी राय में, यह एक स्वीकृत उत्तर हो सकता है। यद्यपि "MAY" पूरी तरह से वैकल्पिक आइटम को इंगित करता है, यह आधिकारिक RFC 7231 प्रलेखन द्वारा सुझाया गया एकमात्र प्रतिक्रिया कोड है ।

— नंदो

16

यह सबसे Restful जवाब है।

— सेठ

6

मुझे लगता है कि संदर्भ महत्वपूर्ण है। उदाहरण के लिए: 303 लौटाने से तात्पर्य है कि पाए गए संसाधन के पुनर्निर्देशन की जरूरत है। एक सर्वर से सर्वर कॉल में इसका मतलब हो सकता है, लेकिन अगर आप उपयोगकर्ता पंजीकरण प्रक्रिया से गुजर रहे हैं, तो इसका कोई मतलब नहीं होगा।

— सिनास्टेटिक

11

क्षमा करें, मैं इसे नीचा दिखा रहा हूं। HTTP 300s पुनर्निर्देशित करने के बारे में हैं, और किसी अन्य ऑब्जेक्ट पर पुनर्निर्देशित करना, जिसमें संभवतः अलग-अलग गुण हैं, बहुत भ्रामक होगा।

— माइकल शीपर

6

आपको क्षमा करने की आवश्यकता नहीं है। हालांकि, यदि प्रतिनिधित्व मौजूदा संसाधन के बराबर है, तो इसके विभिन्न गुण कैसे हो सकते हैं? और यहां तक कि अगर यह होता है, तो एक पुनर्निर्देशन भ्रामक कैसे होगा? ओपी कहता है: मुझे यकीन नहीं है कि वस्तु के पहले से ही वहां क्या करना है। यह वास्तव में 'समान' वस्तु है। एक पुनर्निर्देशन भ्रामक क्यों होगा? आप एक अन्य ऑब्जेक्ट के बारे में बात कर रहे हैं जो ओपी के दिमाग में स्पष्ट रूप से नहीं है।

— नूलियस

86

व्यक्तिगत रूप से मैं WebDAV एक्सटेंशन के साथ जाता हूं 422 Unprocessable Entity।

आरएफसी 4918 के अनुसार

422 Unprocessable Entityस्थिति कोड का अर्थ सर्वर अनुरोध इकाई (इसलिए एक की सामग्री प्रकार समझता 415 Unsupported Media Typeस्थिति कोड अनुचित है), और अनुरोध इकाई की वाक्य रचना सही है (एक प्रकार से 400 Bad Requestस्थिति कोड अनुचित है), लेकिन निहित निर्देशों संसाधित नहीं कर पाया।

— गैरेथ
स्रोत

19

यह एक दिलचस्प विचार है, और मुझे अंततः WebDAV RFC पढ़ने के लिए प्रेरित किया। हालाँकि, मुझे लगता है कि 422 का अर्थ यह है कि अनुरोध और इसमें शामिल इकाई वाक्य-विन्यास सही थे, लेकिन शब्दार्थ से कोई मतलब नहीं था।

— vmj

4

विकृत JSON एक वाक्यात्मक रूप से सही इकाई नहीं है, इसलिए 422मुझे अजीब लगता है ...

— 9

7

मैं इसके साथ नहीं जाऊंगा। उत्तर में संदर्भित उसी URL से: "उदाहरण के लिए, यह त्रुटि स्थिति तब हो सकती है जब किसी XML अनुरोध बॉडी में अच्छी तरह से गठित (यानी, वाक्यविन्यास रूप से सही) हो, लेकिन शब्दार्थ गलत, XML निर्देश।" यह एक असंगत इकाई का वास्तविक अर्थ है, इस मामले के विपरीत जब आप पूरी तरह से मान्य सिंटैक्स और शब्दार्थ के साथ मान्य अनुरोध इकाई भेजते हैं, लेकिन एकमात्र समस्या यह है कि यह एक मौजूदा इकाई के साथ संघर्ष करता है। दरअसल, यदि अनुरोध इकाई के शब्दार्थ मान्य नहीं थे, तो एक समान, मौजूदा इकाई नहीं होनी चाहिए।

— ताम्र श्लेष

1

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

— हरीश

4

@ टैमर ऐसा क्यों? कमांड "कृपया ऑब्जेक्ट xy बनाएं" सिंटैक्टली रूप से सही है। यह केवल वस्तु एक्सवाई बनाने के लिए संभव है, तो शब्दार्थ रूप से सही है। यदि ऑब्जेक्ट xy पहले से मौजूद है, तो इसे अब बनाया नहीं जा सकता है, इसलिए यह एक शब्दार्थ त्रुटि है।

— हेगन वॉन एटिजन

47

यह सब संदर्भ के बारे में है , और यह भी जो अनुरोधों (सर्वर या क्लाइंट या दोनों) में डुप्लिकेट को संभालने के लिए जिम्मेदार है

यदि सर्वर केवल डुप्लिकेट इंगित करता है , तो 4xx देखें:

400 बैड रिक्वेस्ट - जब सर्वर रिक्वेस्ट प्रोसेस नहीं करेगा क्योंकि यह स्पष्ट क्लाइंट फॉल्ट है
409 संघर्ष - यदि सर्वर अनुरोध को संसाधित नहीं करेगा, लेकिन इसका कारण ग्राहक की गलती नहीं है
...

डुप्लिकेट के अंतर्निहित हैंडलिंग के लिए, 2XX देखें:

200 ठीक है
201 बनाया गया
...

यदि सर्वर से कुछ वापसी की उम्मीद है , तो 3XX देखें:

302 मिला
303 अन्य देखें
...

जब सर्वर मौजूदा संसाधन को इंगित करने में सक्षम होता है, तो इसका मतलब पुनर्निर्देशन है।

यदि उपरोक्त पर्याप्त नहीं है, तो प्रतिक्रिया के शरीर में कुछ त्रुटि संदेश तैयार करने के लिए हमेशा एक अच्छा अभ्यास है।

— स्लावोमिर लेनार्ट
स्रोत

2

अनुरोध एक संसाधन की नकल नहीं कर रहा है, यह डेटा को एक में जोड़ रहा है। मेरी राय में, तुम्हारा सबसे अच्छा जवाब है।

— सनकैट २२

28

खेल के लिए देर हो सकती है लेकिन मैं REST API बनाने की कोशिश करते हुए इस शब्दार्थ मुद्दे पर लड़खड़ा गया।

विरिकन के उत्तर पर थोड़ा विस्तार करने के लिए, मुझे लगता है कि आप 409 Conflictया तो उपयोग कर सकते हैं या 403 Forbiddenस्थिति के आधार पर - संक्षेप में, 403 त्रुटि का उपयोग करें जब उपयोगकर्ता संघर्ष को हल करने के लिए कुछ भी नहीं कर सकता है और अनुरोध को पूरा कर सकता है (उदाहरण के लिए वे एक बहुत नहीं भेज सकते हैं) DELETEसंसाधन को स्पष्ट रूप से हटाने का अनुरोध), या यदि संभवत: कुछ किया जा सकता है तो 409 का उपयोग करें।

10.4.4 403 निषिद्ध

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

आजकल, कोई "403" कहता है और एक अनुमति या प्रमाणीकरण समस्या दिमाग में आती है, लेकिन कल्पना कहती है कि यह मूल रूप से सर्वर है जो ग्राहक को बता रहा है कि वह ऐसा नहीं करने जा रहा है, इसे फिर से न पूछें, और यहाँ ग्राहक को क्यों नहीं करना चाहिए 'टी।

के रूप में PUTबनाम POST... POSTसंसाधन के लिए एक पहचानकर्ता नहीं बनाना चाहिए जब उपयोगकर्ता के लिए किसी भी तरह है एक संसाधन का एक नया उदाहरण बनाने के लिए इस्तेमाल किया जाना चाहिए या। PUTका उपयोग तब किया जाता है जब संसाधन की पहचान ज्ञात हो।

9.6 PUT

...

POST और UUT अनुरोधों के बीच मूलभूत अंतर Request-URI के विभिन्न अर्थों में परिलक्षित होता है। POST अनुरोध में URI उस संसाधन की पहचान करता है जो संलग्न इकाई को संभालेगा। वह संसाधन डेटा-स्वीकार करने की प्रक्रिया, कुछ अन्य प्रोटोकॉल का प्रवेश द्वार, या एनोटेशन स्वीकार करने वाली एक अलग इकाई हो सकती है। इसके विपरीत, एक पीयूटी अनुरोध में यूआरआई अनुरोध के साथ संलग्न इकाई की पहचान करता है - उपयोगकर्ता एजेंट जानता है कि यूआरआई क्या है और सर्वर अनुरोध को किसी अन्य संसाधन पर लागू करने का प्रयास नहीं करता है। यदि सर्वर की इच्छा है कि अनुरोध को एक अलग यूआरआई पर लागू किया जाए,

यह 301 भेजना चाहिए (स्थायी रूप से स्थानांतरित) प्रतिक्रिया; उपयोगकर्ता एजेंट MAY तब अनुरोध को पुनर्निर्देशित करने या न करने के संबंध में अपना निर्णय लेता है।

— p0lar_bear
स्रोत

7

मुझे लगता है कि 403 निषिद्ध का तात्पर्य यह है कि उपयोगकर्ता प्रमाणित होने के बावजूद , वह अनुरोधित कार्रवाई को निष्पादित करने के लिए अधिकृत नहीं है। मैं सत्यापन त्रुटियों के लिए इसका उपयोग नहीं करूंगा। उदाहरण : लॉग इन नहीं, मैं कुछ हटाने का प्रयास करता हूं। सर्वर मुझे 401 अनधिकृत भेजता है (जो कि बुरी तरह से नामांकित है, 401 अनहुंटेड होना चाहिए )। मैं लॉग इन करता हूं और फिर से कोशिश करता हूं। इस बार सर्वर मेरी अनुमतियों की जांच करता है, देखता है कि मुझे अनुमति नहीं है और 403 निषिद्ध है । यह प्रश्न भी देखें ।

— Stijn de Witt

हम्म ... सच। यहां सोचा गया था कि उपयोगकर्ता को यह बताने के लिए सही है कि उनके प्राधिकरण ओपी के उपयोग के मामले में संसाधन को अपरिवर्तनीय बनाते हैं - यह पहले से मौजूद है, आपके पास संघर्ष को हल करने के लिए कुछ भी करने की कोई अनुमति नहीं है, फिर से संसाधन बनाने का प्रयास न करें।

— p0lar_bear

3

युक्ति के अनुसार, यह निहित है कि त्रुटि 409 को एक POSTअनुरोध के द्वारा नहीं लौटाया जा सकता है (जब इसे सही तरीके से उपयोग किया जाता है), क्योंकि यह बताता है कि इसे लक्षित संसाधन के साथ संघर्ष होने पर वापस कर दिया जाना चाहिए । चूंकि लक्ष्य संसाधन अभी तक पोस्ट नहीं किया गया है, यह संभवतः संघर्ष नहीं कर सकता है, और इस प्रकार उत्तर 409 Conflictदेने का कोई मतलब नहीं है।

— ग्रांटीकैन

1

मुझे यह अनुमान नहीं होगा कि 409 त्रुटि को वापस नहीं किया जा सकता POSTहै, वास्तव में, मैं इसके विपरीत अनुमान लगाऊंगा क्योंकि " PUT अनुरोध के जवाब में संघर्ष होने की संभावना सबसे अधिक है।" लगता है कि अन्य अनुरोध विधियाँ भी इस कोड का उपयोग कर सकती हैं। इसके अतिरिक्त, "प्रतिक्रिया निकाय में उपयोगकर्ता को संघर्ष के स्रोत को पहचानने के लिए पर्याप्त जानकारी शामिल होनी चाहिए । आदर्श रूप से, प्रतिक्रिया इकाई में उपयोगकर्ता या उपयोगकर्ता एजेंट के लिए समस्या को ठीक करने के लिए पर्याप्त जानकारी शामिल होगी; हालांकि, यह संभव नहीं है और हो सकता है। आवश्यकता नहीं है । " ( webdav.org/specs/rfc2616.html#status.409 )

— JWAspin

14

"302 मिला" मेरे लिए तर्कसंगत लगता है। और RFC 2616 का कहना है कि यह GET और HEAD के अलावा अन्य अनुरोधों के लिए उत्तर दिया जा सकता है (और इसमें निश्चित रूप से POST शामिल है)

लेकिन यह अभी भी आरएफसी द्वारा इस "संस्थापक" संसाधन को प्राप्त करने के लिए इस URL पर जाने वाले आगंतुक को रखता है। इसे असली "फाउंड" URL पर सीधे जाने के लिए "303 See Other" का उपयोग करना चाहिए, जो समझ में आता है, लेकिन इसके बाद के URL को प्राप्त करने के लिए किसी अन्य कॉल को मजबूर करता है। अच्छी तरफ, यह GET उपलब्ध नहीं है।

मुझे लगता है कि मैं "303 अन्य देखें" का उपयोग करेगा । मुझे नहीं पता कि मैं शरीर में पाए जाने वाले "चीज़" के साथ प्रतिक्रिया कर सकता हूं, लेकिन मैं सर्वर पर एक राउंडट्रिप को बचाने के लिए ऐसा करना चाहूंगा।

अद्यतन: आरएफसी फिर से पढ़ने के बाद, मैं अब भी लगता है कि एक गैर-मौजूद "4xx + 303 मिला" कोड सही होना चाहिए। हालांकि, "409 संघर्ष" सबसे अच्छा मौजूदा उत्तर कोड है (जैसा कि @Wrikken द्वारा बताया गया है), शायद मौजूदा संसाधन को इंगित करने वाले किसी स्थान शीर्षलेख सहित।

— alanjds
स्रोत

88

3xx स्थिति पुनर्निर्देशन के लिए होती हैं

— अविराम नेतनल

1

"अनुरोधित संसाधन एक अलग URI के तहत अस्थायी रूप से रहता है।" से w3.org/Protocols/rfc2616/rfc2616-sec10.html

— statueofmike

1

IMHO, "307 अस्थायी पुनर्निर्देशन" वास्तविक अस्थायी पुनर्निर्देश है। "302" अस्पष्ट है, लेकिन "ध्वनि !!" यहाँ वास्तव में वांछित संदेश है। HTTP शब्दार्थ पर सबसे अच्छा समझौता "303 अन्य देखें" है। मैं "303 अन्य देखें" के साथ जाऊंगा।

— alanjds

@DavidVartanian हम ... मैं यहाँ एक त्रुटि नहीं देख रहा हूँ। ग्राहक एक सही अनुरोध भेजते हैं, लेकिन यह कैसे कहें कि "क्षमा करें, लेकिन आप यहां जो बनाने की कोशिश कर रहे हैं वह पहले से ही मौजूद है"? कुछ 3xx के लिए एक नौकरी लगता है। यह मेरे लिए 4xx नहीं है, क्योंकि क्लाइंट की कोई गलती नहीं है।

— alanjds

1

@DavidVartanian चर्चा के लिए धन्यवाद। 409 की ओर उत्तर का अद्यतन करें । क्लाइंट को असंभव सामान के लिए पूछना गलत है, भले ही उसे पता न हो कि यह असंभव है।

— alanjds

11

मुझे नहीं लगता कि आपको ऐसा करना चाहिए।

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

बिना आईडी के किसी आइटम को जोड़ने के लिए इसका उपयोग करें। यह सबसे अच्छा अभ्यास है।

यदि आप एक UNIQUE बाधा (आईडी नहीं) पर कब्जा करना चाहते हैं, तो आप 409 का जवाब दे सकते हैं, जैसा कि आप PUT अनुरोधों में कर सकते हैं। लेकिन आईडी नहीं।

— अल्फांसो टिंडे
स्रोत

एक वस्तु के बारे में क्या है जिसमें एक संबंध तालिका संबंध है? मान लें कि हमारे पास डेटाबेस तालिकाओं के रूप में खाता, उत्पाद और खाता_प्रोडक्ट है। मैं किसी उत्पाद को किसी खाते में जोड़ना चाहता हूं, इसलिए मैं product_id के साथ / account / {id} / उत्पाद पर पोस्ट करना चाहूंगा। यदि केवल एक खाता-उत्पाद संबंध की अनुमति है, तो मुझे क्या लौटना चाहिए?

— partkyle

2

डेटाबेस तालिकाओं को भूल जाओ। मान लीजिए कि एक उत्पाद केवल एक खाते से संबंधित हो सकता है ... तो यह कई संबंधों में से एक है। तो, POST / उत्पाद / {id} {'खाता': account_id} के साथ। यदि आपके पास '1' (एक से एक संबंध) के लिए अधिकतम कार्डिनैलिटी सेट है .... तो उन्हें बाकी वस्तुओं को क्यों अलग किया जाता है? कार्डिनैलिटी की एक त्रुटि सिर्फ 400 गलत होगी। इसे सरल रखें। मुझे आशा है कि मैं आपके प्रश्न को समझ गया हूँ।

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

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

— एलेक्सकोड

पब्लिक आईडी के रूप में पीके का उपयोग करना बंद करो !!

— सिनास्टेटिक

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

— रॉकेट

9

मैं साथ जाऊंगा 422 Unprocessable Entity, जिसका उपयोग किसी अनुरोध के अमान्य होने पर किया जाता है, लेकिन समस्या वाक्यविन्यास या प्रमाणीकरण में नहीं है।

अन्य उत्तरों के विरुद्ध एक तर्क के रूप में, किसी भी गैर- 4xxत्रुटि कोड का उपयोग करने के लिए इसका मतलब यह नहीं होगा कि यह एक ग्राहक त्रुटि है, और यह स्पष्ट रूप से है। 4xxएक ग्राहक त्रुटि का प्रतिनिधित्व करने के लिए एक गैर त्रुटि कोड का उपयोग करने के लिए बस कोई मतलब नहीं है।

ऐसा लगता है कि 409 Conflictयहां सबसे आम उत्तर है, लेकिन, कल्पना के अनुसार, इसका मतलब है कि संसाधन पहले से मौजूद है और आप जिस नए डेटा पर इसे लागू कर रहे हैं वह इसकी वर्तमान स्थिति के साथ असंगत है। अगर आप a भेज रहे हैंPOSTअनुरोध, उदाहरण के लिए, एक उपयोगकर्ता नाम जो पहले से ही लिया गया है, यह वास्तव में लक्ष्य संसाधन के साथ संघर्ष नहीं कर रहा है, क्योंकि लक्ष्य संसाधन (जिस संसाधन को आप बनाने की कोशिश कर रहे हैं) अभी तक पोस्ट नहीं किया गया है। यह विशेष रूप से संस्करण नियंत्रण के लिए एक त्रुटि है, जब संग्रहीत संसाधन के संस्करण और अनुरोधित संसाधन के संस्करण के बीच संघर्ष होता है। यह उस उद्देश्य के लिए बहुत उपयोगी है, उदाहरण के लिए जब क्लाइंट ने संसाधन का एक पुराना संस्करण कैश किया है और उस गलत संस्करण के आधार पर एक अनुरोध भेजता है जो अब सशर्त रूप से मान्य नहीं होगा। "इस मामले में, प्रतिक्रिया प्रतिनिधित्व में संशोधन इतिहास के आधार पर मतभेदों के विलय के लिए उपयोगी जानकारी होगी।" उस उपयोगकर्ता नाम के साथ एक और उपयोगकर्ता बनाने का अनुरोध सिर्फ अनप्रोसेबल है, जिसका संस्करण नियंत्रण से कोई लेना-देना नहीं है।

जब आप उपयोग में पहले से ही नाम से रिपॉजिटरी बनाने की कोशिश करते हैं, तो रिकॉर्ड के लिए, 422 भी स्थिति कोड GitHub का उपयोग करता है।

— ग्रांटिक्सन
स्रोत

422 webdav युक्ति है, इसलिए मैं इसे REST API के लिए उपयोग करने की सलाह नहीं

— दूंगा

7

मुझे लगता है कि आरईएसटी के लिए, आपको बस उस विशेष प्रणाली के लिए व्यवहार पर निर्णय लेना होगा, जिस स्थिति में, मुझे लगता है कि "सही" उत्तर यहां दिए गए कुछ युगल उत्तरों में से एक होगा। यदि आप अनुरोध को रोकना और व्यवहार करना चाहते हैं जैसे कि ग्राहक ने गलती की है जिसे जारी रखने से पहले इसे ठीक करने की आवश्यकता है, तो 409 का उपयोग करें। यदि संघर्ष वास्तव में महत्वपूर्ण नहीं है और अनुरोध को जारी रखना चाहते हैं, तो पुनर्निर्देशित करके जवाब दें। उस इकाई को क्लाइंट जो मिला था। मुझे लगता है कि उचित REST एपीआई को पुनर्निर्देशित किया जाना चाहिए (या कम से कम स्थान हेडर प्रदान करते हुए) उस संसाधन के लिए किसी पोस्ट को वैसे भी प्राप्त करना चाहिए, इसलिए यह व्यवहार एक सुसंगत अनुभव देगा।

संपादित करें: यह भी ध्यान देने योग्य है कि आपको आईडी प्रदान करने के बाद से आपको एक PUT पर विचार करना चाहिए। तब व्यवहार सरल है: "मुझे परवाह नहीं है कि अभी क्या है, इस बात को वहां रखें।" मतलब, अगर कुछ नहीं है, तो इसे बनाया जाएगा; अगर कुछ है तो उसे बदल दिया जाएगा। मुझे लगता है कि जब सर्वर उस आईडी का प्रबंधन करता है तो एक POST अधिक उपयुक्त होता है। मूल रूप से दो अवधारणाओं को अलग करना आपको बताता है कि इससे कैसे निपटा जाए (यानी पीयूटी बेमिसाल है इसलिए इसे हमेशा इतना लंबा काम करना चाहिए जब तक पेलोड मान्य हो जाए, POST हमेशा बन जाता है, इसलिए यदि आईडी की टक्कर होती है, तो 409 उस संघर्ष का वर्णन करेगा) ।

— Sinaesthetic
स्रोत

युक्ति के अनुसार, यह निहित है कि त्रुटि 409 को एक POSTअनुरोध के द्वारा नहीं लौटाया जा सकता है (जब इसे सही तरीके से उपयोग किया जाता है), क्योंकि यह बताता है कि इसे लक्षित संसाधन के साथ संघर्ष होने पर वापस कर दिया जाना चाहिए । चूंकि लक्ष्य संसाधन अभी तक पोस्ट नहीं किया गया है, यह संभवतः संघर्ष नहीं कर सकता है, और इस प्रकार उत्तर 409 Conflictदेने का कोई मतलब नहीं है।

— ग्रांटीकैन

डिबेटेबल इमो। यदि आप / उपयोगकर्ताओं के लिए पोस्ट करते हैं, तो संसाधन व्यक्तिगत रिकॉर्ड / उपयोगकर्ताओं / {आईडी} के बजाय संग्रह है

— सिनास्टैटिक

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

— ग्रांटिकन

मुझे आपके सुझाव का उपयोग करना पसंद है PUT।

— ग्रांटिकन

4

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

PATCH आपको पहले से मौजूद आइटम को अपडेट करने की अनुमति देकर समस्या का समाधान करेगा। देखें: RFC 5789: PATCH

— मार्टिन केर्स्टन
स्रोत

2

पैच PUT जैसा है लेकिन पूर्ण प्रतिस्थापन नहीं है। इसका उपयोग संसाधन के एक टुकड़े को जोड़ने, हटाने, या एक पूरे के रूप में प्रतिस्थापित करने के बजाय संसाधन के एक तत्व को संशोधित करने के लिए किया जाता है।

— सिनास्टेटिक

4

क्यों नहीं 202 स्वीकार किए जाते हैं ? यह एक ठीक अनुरोध (200s) है, प्रति ग्राहक कोई त्रुटि (400s) नहीं थे।

से 10 स्थिति कोड परिभाषाएँ :

"202 स्वीकृत। प्रसंस्करण के लिए अनुरोध स्वीकार कर लिया गया है, लेकिन प्रसंस्करण पूरा नहीं हुआ है।"

... क्योंकि इसे पूरा करने की आवश्यकता नहीं थी, क्योंकि यह पहले से मौजूद था। ग्राहक यह नहीं जानता कि यह पहले से मौजूद है, उन्होंने कुछ भी गलत नहीं किया।

मैं एक 202 फेंकने पर झुक रहा हूं, और एक जीईटी क्या लौटाता है उसी तरह की सामग्री वापस कर रहा हूं /{resource}/{id}।

— फिलिप हैरिंगटन
स्रोत

21

यह उत्तर गलत है। 202 का मतलब है कि सर्वर को अनुरोध के साथ कोई समस्या नहीं मिली, लेकिन जवाब देने के बाद अनुरोध को संसाधित करने के लिए चुना। इसका यह भी अर्थ है कि यह अपेक्षा करता है कि प्रसंस्करण सफल हो। हमारे मामले में सर्वर जानता है कि प्रसंस्करण विफल हो जाएगा, इसलिए 202 गलत प्रतिक्रिया है।

— एड्रियन

4

202 का उदाहरण कतार या सदस्यता होगा। दूसरे शब्दों में, अनुरोध का परिणाम तुरंत उपलब्ध नहीं हो सकता है यदि आप इसे इस क्षण ठीक करना चाहते हैं।

— सिनास्टेटिक

1

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

— सनकैट २२

ग्राहक से यह कहने में कोई मतलब नहीं है कि अनुरोध स्वीकार कर लिया गया था क्योंकि आप पहले से ही जानते हैं कि यह नहीं था!

— ल्यूकास्टामायोस

1

@ Adrian और lucastamoios मुझे लगता है कि आप दोनों प्रतिक्रिया प्रदान करने से पहले सर्वर को डेटाबेस से सिंक्रोनस रीडिंग मान रहे हैं। यह हमेशा मामला नहीं होता है, इसलिए यह उत्तर "गलत" नहीं है, क्योंकि सर्वर हमेशा मौजूदा रिकॉर्ड के बारे में "नहीं" जानता है। यह अतुल्यकालिक प्रणालियों में बहुत अधिक मामला है जहां एपीआई परत केवल पृष्ठभूमि श्रमिकों द्वारा प्रसंस्करण के लिए अनुरोधों को रिकॉर्ड करता है।

— gasaslis

2

डुप्लिकेट रिकॉर्ड के लिए सही कोड की जाँच करते समय इस सवाल पर ठोकर खाई।

मेरी अज्ञानता को क्षमा करें, लेकिन मुझे समझ में नहीं आता कि हर कोई "300" कोड को क्यों अनदेखा कर रहा है, जो स्पष्ट रूप से "बहुविकल्पी" या "अशिष्टता" कहता है

मेरी राय में यह अपने स्वयं के उपयोग के लिए एक गैर मानक या किसी विशेष प्रणाली के निर्माण के लिए सही कोड होगा। मैं भी गलत हो सकता है!

https://tools.ietf.org/html/rfc7231#section-6.4.1

— अंदर मारा
स्रोत

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

— म्यूज़िक

शब्दार्थ, क्लाइंट "इसे बनाएं" कह रहा है और सर्वर "इसके बजाय यहां जाएं" कहकर जवाब दे रहा है। बातचीत का कोई मतलब नहीं है। यह लगभग ऐसा है जैसे कि सर्वर क्लाइंट को "इसके स्थान पर पोस्ट करने" के लिए कह रहा है। 300 GET अनुरोध या POST के मामले में अधिक उपयुक्त प्रतिक्रिया है जब सर्वर "ठीक है, मैंने इसे बनाया है और यह यहां खत्म हो गया है" के साथ जवाब दे रहा है ..

— सिनास्टैटिक

2

अधिक संभावना यह है 400 Bad Request

6.5.1। 400 गलत अनुरोध

400 (खराब अनुरोध) स्थिति कोड इंगित करता है कि सर्वर क्लाइंट त्रुटि के कारण होने वाली चीज़ के कारण अनुरोध को संसाधित नहीं कर सकता है या नहीं करेगा (उदाहरण के लिए, विकृत अनुरोध वाक्यविन्यास, अमान्य अनुरोध संदेश फ़्रेमिंग, या भ्रामक अनुरोध रूटिंग)।

जैसा कि अनुरोध में डुप्लिकेट मान (पहले से मौजूद मूल्य) है, इसे क्लाइंट त्रुटि के रूप में माना जा सकता है। अगली कोशिश से पहले अनुरोध को बदलने की आवश्यकता है।
इन तथ्यों पर विचार करके हम HTTP स्टेटस 400 बैड रिक्वेस्ट के रूप में निष्कर्ष निकाल सकते हैं।

— मोहम्मद सुरक्षित
स्रोत

1

खराब अनुरोध का मतलब है कि पैकेट के सिंटैक्स के साथ एक अंतर्निहित समस्या है। तो किसी अन्य संदर्भ में (जैसे संसाधन पहले से ही विद्यमान नहीं), पैकेट कामयाब होने की, तो यह त्रुटि 400 वापस नहीं चाहिए

— अनुदान Gryczan

1

208 के बारे में क्या - http://httpstatusdogs.com/208-already-reported ? क्या वह विकल्प है?

मेरी राय में, यदि एकमात्र चीज दोहराए जाने वाला संसाधन है तो कोई त्रुटि नहीं उठानी चाहिए। आखिरकार, क्लाइंट या सर्वर पक्षों पर न तो कोई त्रुटि है।

— फर्नांडो फरेरा
स्रोत

यह कोई विकल्प नहीं है क्योंकि आप एक निश्चित आइटम को जोड़ना चाहते हैं जो आईडी पहले से मौजूद है। तो आप कुछ जोड़ने की कोशिश करते हैं लेकिन यह पहले से ही है। एक ओके केवल तभी लागू होगा जब डेटा सेट को विकसित किया गया था। कुछ जोड़ो -> ठीक है मैंने कुछ नहीं किया। फिट नहीं है, मुझे लगता है।

— मार्टिन केर्स्टन

जैसा कि मैंने कहा, मुझे नहीं लगता कि यह एक त्रुटि है। लेकिन मुझे

— फर्नांडो फरेरा

यदि संसाधन सफलतापूर्वक नहीं बनाया गया है, तो परिभाषा में एक त्रुटि है।

— ग्रांटिकन

POST का उपयोग डेटा अपड करने के लिए भी किया जाता है। यह परिभाषा के अनुसार है , त्रुटि नहीं है ।

— सनकैट २२

@ Suncat2000 यहां तक कि यह मामला है, यदि डेटा सफलतापूर्वक जोड़ा नहीं गया है, वहाँ अभी भी एक त्रुटि है। और यदि संसाधन पहले से मौजूद है, तो कोई डेटा जोड़ा नहीं जा सकता है।

— ग्रांटिकन