यदि विभिन्न क्रियाएं अलग-अलग स्थितियों के साथ समाप्त होती हैं, तो लौटने के लिए HTTP स्थिति कोड क्या है?

72

मैं एक एपीआई का निर्माण कर रहा हूं जहां उपयोगकर्ता सर्वर को एक HTTP अनुरोध में कई कार्यों को करने के लिए कह सकता है। परिणाम एक JSON सरणी के रूप में लौटाया जाता है, जिसमें प्रति क्रिया एक प्रविष्टि होती है।

इनमें से प्रत्येक क्रिया विफल हो सकती है या एक दूसरे से स्वतंत्र रूप से सफल हो सकती है। उदाहरण के लिए, पहली कार्रवाई सफल हो सकती है, दूसरी कार्रवाई के लिए इनपुट खराब स्वरूपित हो सकता है और मान्य करने में विफल हो सकता है और तीसरी कार्रवाई अप्रत्याशित त्रुटि का कारण हो सकती है।

यदि प्रति कार्य के लिए एक अनुरोध था, तो मैं क्रमशः 200, 422 और 500 के कोड कोड लौटा दूंगा। लेकिन अब जब केवल एक ही अनुरोध है, तो मुझे किस स्थिति कोड को वापस करना चाहिए?

कुछ विकल्प:

हमेशा 200 वापस करें, और शरीर में अधिक विस्तृत जानकारी दें।
हो सकता है कि उपरोक्त नियम का पालन तभी करें जब अनुरोध में एक से अधिक कार्य हों?
हो सकता है कि सभी अनुरोध सफल होने पर 200 वापस हो, अन्यथा 500 (या कोई अन्य कोड)?
बस प्रति कार्य एक अनुरोध का उपयोग करें, और अतिरिक्त ओवरहेड को स्वीकार करें।
कुछ पूरी तरह से अलग?

api http

— ऐन्डर्स
स्रोत

3

आपके सवाल ने मुझे एक दूसरे के बारे में सोचने पर

— मजबूर कर दिया

7

: थोड़ा के साथ-साथ संबंधित programmers.stackexchange.com/questions/305250/... (HTTP स्थिति कोड और आवेदन कोड के बीच अलगाव के बारे में स्वीकार किए जाते हैं जवाब देखें)

4

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

— ल्यूक फ्रेंकेन

5

ठीक है, उस मामले में मैं दृढ़ता से अन्य क्षेत्रों में उस प्रदर्शन को बेहतर बनाने का सुझाव दूंगा। इस जटिलता को अपनी व्यावसायिक परत में लागू करने से पहले आशावादी ui, अनुरोध बैचिंग, कैशिंग आदि जैसी चीजों का प्रयास करें। क्या आपके पास स्पष्ट अंतर्दृष्टि है कि आप ज्यादातर समय कहां खोते हैं?

— ल्यूक फ्रेंकिन

4

... बहुत उम्मीद नहीं है कि लोग उन स्थितियों को सही ढंग से देखेंगे। अधिकांश कार्यक्रम केवल सबसे सामान्य लोगों के लिए जाँच करते हैं और यदि उन्हें एक अप्रत्याशित स्थिति कोड मिलता है तो वे विफल या दुर्व्यवहार करते हैं। (मुझे याद है कि रैंडल एक्जिट स्टेटस भेजकर अपनी साइट को क्रॉलर से बचाने के बारे में डेफकॉन में एक प्रेजेंटेशन था जिसे ब्राउजर नजरअंदाज कर देता है और बस दिखाता है कि क्रॉलर कभी-कभी गलतियां क्यों करते हैं और इस तरह आपकी वेबसाइट के उस हिस्से को क्रॉल करना बंद कर देते हैं)।

— बाकूरी

21

संक्षिप्त, सीधा उत्तर

चूंकि अनुरोध कार्यों की सूची को निष्पादित करने की बात करता है (कार्य वह संसाधन हैं जो हम यहां बोल रहे हैं), फिर यदि कार्य समूह को निष्पादन के लिए आगे बढ़ाया गया है (अर्थात, निष्पादन परिणाम की परवाह किए बिना), तो यह समझदार होगा कि प्रतिक्रिया की स्थिति होगी 200 OK। अन्यथा, यदि कोई समस्या थी जो कार्य समूह के निष्पादन को रोकती है, जैसे कि कार्य वस्तुओं का सत्यापन विफल होना , या कुछ आवश्यक सेवा उदाहरण के लिए उपलब्ध नहीं है, तो प्रतिक्रिया की स्थिति को उस त्रुटि को निरूपित करना चाहिए। विगत कि, जब कार्यों का निष्पादन शुरू होता है, प्रदर्शन करने के कार्यों के रूप में अनुरोध निकाय में सूचीबद्ध होते हैं, तो मैं उम्मीद करूंगा कि निष्पादन परिणाम प्रतिक्रिया निकाय में सूचीबद्ध होंगे।

लंबा, दार्शनिक जवाब

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

ऊपर कहा जा रहा है, और साहस के बिना इस जवाब को एक लंबी राय वाले गाइड में बदलने के लिए, निम्नलिखित एक यूआरआई योजना है जो एक संसाधन प्रबंधन दृष्टिकोण के अनुरूप है:

/tasks
- GET सभी कार्यों को सूचीबद्ध करता है
- POST एकल कार्य जोड़ता है
/tasks/task/[id]
- GET किसी एक कार्य की राज्य वस्तु के साथ प्रतिक्रिया करता है
- DELETE किसी कार्य को रद्द / हटा देता है
/tasks/groups
- GET सभी कार्य समूहों को सूचीबद्ध करता है
- POST कार्यों का एक समूह जोड़ता है
/tasks/groups/group/[id]
- GET एक कार्य समूह की स्थिति के साथ प्रतिक्रिया करता है
- DELETE कार्य समूह को रद्द / हटा देता है

यह संरचना संसाधनों के बारे में बात करती है, न कि उनके साथ क्या करना है। संसाधनों के साथ जो किया जा रहा है वह दूसरी सेवा की चिंता है।

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

HTTP इंटरफ़ेस को डिज़ाइन करने की ओर कदम बढ़ाते हुए कि संसाधनों को सख्ती से प्रबंधित करने की संभावना है, जब एक बटन पर क्लिक करने पर UI थ्रेड से दूर काम करना मुश्किल होता है। यह आवश्यक है कि HTTP सर्वर अनुरोध हैंडलर में निष्पादित करने के बजाय कार्यों को निष्पादित करने के लिए अन्य सेवाओं के साथ संचार करता है। यह उथला कार्यान्वयन नहीं है, यह दिशा में बदलाव है।

ऐसी URI योजना का उपयोग कैसे किया जाएगा इसके कुछ उदाहरण

एकल कार्य निष्पादित करना और प्रगति पर नज़र रखना:

POST /tasks कार्य निष्पादित करने के लिए
- GET /tasks/task/[id]completedवर्तमान स्थिति / प्रगति दिखाते समय प्रतिक्रिया वस्तु का सकारात्मक मूल्य है

किसी एक कार्य को निष्पादित करना और उसके पूरा होने की प्रतीक्षा करना:

POST /tasks कार्य निष्पादित करने के लिए
- GET /tasks/task/[id]?awaitCompletion=trueजब तक completedसकारात्मक मूल्य नहीं है (संभावना समय समाप्त हो गई है, यही कारण है कि यह लूप होना चाहिए)

कार्य समूह को निष्पादित करना और प्रगति पर नज़र रखना:

POST /tasks/groups निष्पादित करने के लिए कार्यों के समूह के साथ
- GET /tasks/groups/group/[groupId]जब तक प्रतिक्रिया ऑब्जेक्ट completedसंपत्ति का मूल्य नहीं है, व्यक्तिगत कार्य स्थिति दिखा रहा है (उदाहरण के लिए 5 में से 3 कार्य पूरे हो चुके हैं)

किसी कार्य समूह के लिए निष्पादन का अनुरोध करना और उसके पूरा होने की प्रतीक्षा करना:

POST /tasks/groups निष्पादित करने के लिए कार्यों के समूह के साथ
- GET /tasks/groups/group/[groupId]?awaitCompletion=true जब तक पूरा होने वाले परिणाम का जवाब नहीं दिया जाता (तब तक समय समाप्त हो चुका होता है, इसीलिए लूप किया जाना चाहिए)

— बेन बर्काय
स्रोत

मुझे लगता है कि इस बारे में बात करना अर्थपूर्ण है कि इससे संपर्क करने का सही तरीका क्या है। धन्यवाद!

— एंडर्स

2

मैं इस जवाब का प्रस्ताव करने जा रहा था अगर यह पहले से ही वहाँ नहीं था। यह है असंभव एक भी HTTP अनुरोध में एक से अधिक अनुरोध बनाने के लिए। दूसरी ओर, एक एकल HTTP अनुरोध करना पूरी तरह से संभव है जो कहता है कि "निम्नलिखित क्रियाएं करें, और मुझे बताएं कि परिणाम क्या हैं"। और यहां यही हो रहा है।

— मार्टिन कोचानस्की

मैं इस जवाब को स्वीकार करूंगा यहां तक कि सबसे मतों से भी दूर है। जबकि अन्य उत्तर भी अच्छे हैं, मुझे लगता है कि यह केवल वही है जो HTTP के शब्दार्थों के बारे में है।

— एंडर्स

87

मेरा वोट इन कार्यों को अलग-अलग अनुरोधों में विभाजित करना होगा। हालाँकि, अगर कई राउंड ट्रिप एक चिंता का विषय हैं, तो मैं HTTP प्रतिक्रिया कोड 207 - मल्टी-स्टेटस में आया हूं

इस लिंक से कॉपी / पेस्ट करें:

एक बहु-स्थिति प्रतिक्रिया उन स्थितियों में कई संसाधनों के बारे में जानकारी देती है जहां कई स्थिति कोड उपयुक्त हो सकते हैं। डिफ़ॉल्ट मल्टी-स्टेटस प्रतिक्रिया निकाय एक पाठ / xml या अनुप्रयोग / xml HTTP इकाई है जिसमें 'मल्टीस्टैटस' मूल तत्व होता है। आगे के तत्वों में विधि आह्वान के दौरान उत्पन्न 200, 300, 400 और 500 श्रृंखला स्थिति कोड शामिल हैं। 100 श्रृंखला स्थिति कोड SHOULD को 'प्रतिक्रिया' XML तत्व में दर्ज नहीं किया जाना चाहिए।

यद्यपि '207' का उपयोग समग्र प्रतिक्रिया स्थिति कोड के रूप में किया जाता है, प्राप्तकर्ता को विधि निष्पादन की सफलता या विफलता के बारे में अधिक जानकारी के लिए मल्टीस्टैटस प्रतिक्रिया निकाय की सामग्री से परामर्श करने की आवश्यकता होती है। प्रतिक्रिया MAY का उपयोग सफलता, आंशिक सफलता और विफलता की स्थितियों में भी किया जाना चाहिए।

— neilsimp1
स्रोत

22

207ऐसा लगता है कि ओपी क्या चाहता है, लेकिन मैं वास्तव में इस बहु-अनुरोध-इन-वन दृष्टिकोण के लिए एक बुरा विचार करना चाहता हूं। यदि चिंता प्रदर्शन है, तो आपको क्लाउड-स्टाइल क्षैतिज रूप से स्केलेबल सिस्टम के लिए आर्किटेक्चर होना चाहिए (जो कि HTTP- आधारित सिस्टम बहुत बढ़िया हैं)

— डेविड ग्रिनबर्ग

44

@DavidGrinberg मैं इससे अधिक असहमत नहीं हो सकता। यदि व्यक्तिगत क्रियाएं सस्ती हैं, तो एक अनुरोध को संभालने का ओवरहेड कार्रवाई से बहुत अधिक महंगा हो सकता है। आपका सुझाव उन परिदृश्यों को जन्म दे सकता है जहां एक डेटाबेस में कई पंक्तियों को अद्यतन करने के लिए प्रति पंक्ति एक अलग लेनदेन का उपयोग किया जाता है क्योंकि प्रत्येक पंक्ति को एक अलग अनुरोध के रूप में भेजा जाता है। यह न केवल बहुत ही अयोग्य है, बल्कि इसका मतलब यह भी है कि जरूरत पड़ने पर कई पंक्तियों को परमाणु रूप से अद्यतन करना संभव नहीं होगा। क्षैतिज स्केलिंग महत्वपूर्ण है लेकिन यह कुशल डिजाइनों का प्रतिस्थापन नहीं है।

— 19

4

अच्छी तरह से कहा और प्रदर्शन और / या परमाणु जैसे व्यावसायिक जरूरतों की वास्तविकताओं के प्रति अनभिज्ञ लोगों द्वारा किए गए REST एपीआई कार्यान्वयन के एक विशिष्ट मुद्दे की ओर इशारा करते हैं। यही कारण है कि, उदाहरण के लिए, ओडटा रीस्ट विनिर्देश में एक कॉल में बहु संचालन के लिए एक बैच प्रारूप है - इसके लिए एक वास्तविक आवश्यकता है।

— टॉमटॉम

8

@TomTom, ओपी परमाणु क्षमता नहीं चाहता है। यह डिजाइन करने के लिए बहुत आसान चीज होगी, क्योंकि परमाणु ऑपरेशन की केवल एक स्थिति है। इसके अलावा, HTTP युक्ति HTTP / 2 मल्टीप्लेक्सिंग के माध्यम से (स्वाभाविक रूप से, HTTP / 2 समर्थन एक और मामला है, लेकिन युक्ति इसके लिए अनुमति देता है) प्रदर्शन के लिए संचालन को बैचने की अनुमति देता है।

— पॉल ड्रेपर

2

@ डेविड ने अतीत में कुछ एचपीसी समस्याओं पर काम किया है, मेरे अनुभव में एक सिंगल बाइट भेजने की लागत बहुत अधिक है एक हज़ार भेजने के रूप में (अलग-अलग ट्रांसफर माध्यमों के अलग-अलग ओवरहेड निश्चित रूप से हैं, लेकिन यह शायद ही कभी इस से बेहतर है)। इसलिए यदि प्रदर्शन एक चिंता का विषय है, तो मैं यह नहीं देखता कि कैसे कई अनुरोध भेजने से एक बड़ा ओवरहेड नहीं होगा। यदि आप एक ही कनेक्शन पर कई अनुरोधों को मल्टीप्लेक्स कर सकते हैं तो यह समस्या गायब हो जाएगी, लेकिन जैसा कि मैं इसे समझता हूं, यह केवल HTTP / 2 के साथ एक विकल्प है और इसके लिए समर्थन सीमित है। या क्या मैं कुछ न कुछ भूल रहा हूं?

— वू

24

हालाँकि, बहु-स्थिति एक विकल्प है, मैं 200 (सभी अच्छी तरह से) वापस करूँगा यदि सभी अनुरोध सफल हुए और एक त्रुटि (500 या शायद 207) अन्यथा।

मानक मामला आमतौर पर 200 होना चाहिए - सब कुछ काम करता है। और ग्राहकों को केवल उसके लिए जांच करनी चाहिए। और केवल अगर त्रुटि-मामला हुआ, तो आप 500 (या 207) वापस कर सकते हैं। मुझे लगता है कि 207 कम से कम एक त्रुटि के मामले में एक वैध विकल्प है, लेकिन अगर आप पूरे पैकेज को एक लेन-देन के रूप में देखते हैं तो आप 500 भी भेज सकते हैं। - ग्राहक त्रुटि-संदेश की व्याख्या करना चाहेंगे।

हमेशा 207 क्यों नहीं भेजे? - क्योंकि मानक मामले आसान और मानक होने चाहिए। जबकि असाधारण मामले असाधारण हो सकते हैं। एक ग्राहक को केवल प्रतिक्रिया निकाय को पढ़ना चाहिए और आगे के जटिल निर्णय लेने चाहिए, यदि कोई असाधारण स्थिति इसे दर्ज करती है।

— फाल्को
स्रोत

6

मैं काफी सहमत नहीं हूँ। यदि उपश्रेणी 1 और 3 सफल हुई, तो आपको एक संयुक्त संसाधन मिलता है और संयुक्त प्रतिक्रिया को वैसे भी जांचना होता है। आपके पास विचार करने के लिए बस एक और मामला है। यदि प्रतिक्रिया = 200 या उपप्रकार 1 = 200 है तो अनुरोध 1 सफल हुआ। यदि प्रतिक्रिया = 200 या उपप्रकार 2 = 200 है तो अनुरोध 2 सफल और इसी तरह केवल उप प्रतिक्रिया का परीक्षण करने के बजाय।

— gnasher729

1

@ gnasher729 यह वास्तव में आवेदन पर निर्भर करता है। मैं एक उपयोगकर्ता-संचालित कार्रवाई की कल्पना करता हूं, जो सभी अनुरोधों के सफल होने पर बस (सब कुछ ठीक है) अगले चरण में प्रवाहित होगी। - अगर कुछ भी गलत हुआ (वैश्विक स्थिति <= 200) तो आपको विस्तृत त्रुटियों को प्रदर्शित करना होगा और वर्कफ़्लो को बदलना होगा, और केवल प्रत्येक सबरेक्वेस्ट के लिए एक ही चेक की आवश्यकता होगी, क्योंकि आप "हैंडलमिक्सडस्ट" फ़ंक्शन में हैं और "हैंडल" नहीं हैं। ।

— फाल्को

यह वास्तव में इसका मतलब क्या है पर निर्भर करता है। उदाहरण के लिए मेरे पास एक समापन बिंदु है जो ट्रेडिंग रणनीतियों को नियंत्रित करता है। आप एक रन में पहचानकर्ताओं की एक सूची "शुरू" कर सकते हैं। रिटर्न 200 का मतलब है ऑपरेशन (उन्हें प्रोसेस करना) सफल - लेकिन सभी सफलतापूर्वक शुरू नहीं हो सकते। जो, btw।, तत्काल परिणाम में भी नहीं देखा जा सकता है (जो शुरू होगा) क्योंकि स्टार्टअप को कुछ सेकंड लग सकते हैं। मल्टी ऑपरेशन कॉल में शब्दार्थ परिदृश्य पर निर्भर करता है।

— टॉमटॉम

अगर कोई सामान्य समस्या (जैसे डेटाबेस डाउन) होती है तो मैं भी सबसे अधिक 500 भेज सकता हूं, इसलिए सर्वर व्यक्तिगत अनुरोधों को भी नहीं आज़माता है, लेकिन सामान्य त्रुटि वापस कर सकता है। - क्योंकि उपयोगकर्ता के लिए 3 अलग-अलग परिणाम हैं 1. सभी ठीक है, 2. सामान्य समस्या, कुछ भी काम नहीं करता है, 3. कुछ अनुरोध विफल रहे। -> जो आमतौर पर एक पूरी तरह से अलग कार्यक्रम-प्रवाह का नेतृत्व करेगा।

— फाल्को

1

ठीक है, इसलिए एक दृष्टिकोण होगा: 207 = प्रत्येक अनुरोध के लिए व्यक्तिगत स्थिति। और कुछ भी: हर अनुरोध पर स्थिति वापस आ जाती है। 200, 401,। 500 के लिए समझ में आता है

— gnasher729

13

एक विकल्प हमेशा एक स्थिति कोड 200 को वापस करना और फिर अपने JSON दस्तावेज़ निकाय में विशिष्ट त्रुटियों को वापस करना होगा। यह ठीक इसी तरह है कि कुछ एपीआई डिज़ाइन किए गए हैं (वे हमेशा एक स्थिति कोड 200 लौटाते हैं और शरीर में त्रुटि भेजते हैं)। विभिन्न तरीकों के बारे में अधिक जानकारी के लिए, http://archive.oreilly.com/pub/post/restful_error_handling.html देखें

— BigONotation
स्रोत

2

इस मामले में, मुझे लगता 200है कि सभी को इंगित करने के लिए उपयोग करने का विचार अच्छा है, अनुरोध प्राप्त हुआ है और मान्य था , और फिर उस अनुरोध में क्या हुआ (यानी लेनदेन का परिणाम) पर विवरण प्रदान करने के लिए JSON का उपयोग करें।

— अक्टूबर को rickcnagy

4

मुझे लगता है कि neilsimp1 सही है, लेकिन मैं इस तरह से भेजे जा रहे डेटा को फिर से डिज़ाइन करने की सलाह दूंगा ताकि आप 206 - Acceptedबाद में डेटा भेज सकें और उसे संसाधित कर सकें । शायद कॉलबैक के साथ।

एक ही अनुरोध में कई कार्यों को भेजने की कोशिश के साथ समस्या बिल्कुल यह है कि प्रत्येक कार्रवाई की अपनी "स्थिति" होनी चाहिए

CSV आयात करने को देखते हुए (मुझे नहीं पता कि वास्तव में ओपी क्या है लेकिन यह एक सरल संस्करण है)। CSV को पोस्ट करें और एक 206 प्राप्त करें। बाद में CSV को आयात किया जा सकता है और आप प्रति पंक्ति त्रुटियों को दिखाने वाले URL के खिलाफ GET (200) के साथ आयात की स्थिति प्राप्त कर सकते हैं।

POST /imports/ -> 206
GET  /imports/1 -> 200
GET  /imports/1/errors -> 200 -> Has a list of errors

यह एक ही पैटर्न कई बैच opterations के लिए लागू किया जा सकता है

POST /operations/ -> 206
GET  /operations/1 -> 200
GET  /operations/1/errors -> 200 - > Has a list of errors.

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

— coteyr
स्रोत

2

यहाँ पहले से ही कई अच्छे उत्तर हैं, लेकिन एक पहलू गायब है:

आपके ग्राहकों को क्या अनुबंध की उम्मीद है?

HTTP रिटर्न कोड को कम से कम एक सफलता / असफलता का संकेत देना चाहिए और इस तरह "गरीब आदमी का अपवाद" की भूमिका निभानी चाहिए। फिर 200 का अर्थ है "अनुबंध पूरी तरह से पूरा", और 4xx या 5xx को पूरा करने में विफलता का संकेत देते हैं।

स्वाभाविक रूप से, मुझे आपके कई कार्यों के अनुबंध की उम्मीद है कि "मेरे सभी कार्य करें", और यदि उनमें से कोई भी विफल रहता है, तो अनुरोध सफल नहीं हुआ। आमतौर पर, एक ग्राहक के रूप में मैं 200 को "सब कुछ ठीक" समझूंगा, और 400 और 500 परिवार के कोड मुझे एक (आंशिक) विफलता के परिणामों के बारे में सोचने के लिए मजबूर करेंगे। तो, "सभी किए गए कार्यों" के लिए 200 और आंशिक विफलता के मामले में 500 प्लस एक वर्णनात्मक प्रतिक्रिया का उपयोग करें।

एक अलग काल्पनिक अनुबंध "सभी कार्यों को करने का प्रयास" हो सकता है। तब यह पूरी तरह से अनुबंध के अनुरूप है यदि (कुछ) कार्रवाई विफल हो जाती है। इसलिए आप हमेशा 200 से अधिक परिणाम दस्तावेज वापस करेंगे, जहां आपको व्यक्तिगत कार्यों के लिए सफलता / विफलता की जानकारी मिलती है।

तो, आप किस अनुबंध का पालन करना चाहते हैं? दोनों मान्य हैं, लेकिन पहले एक (200 केवल मामले में सब कुछ किया गया था) मेरे लिए अधिक सहज है, और विशिष्ट सॉफ्टवेयर पैटर्न के अनुरूप बेहतर है। और (उम्मीद है) मामलों के बहुमत के लिए जहां सेवा ने सभी कार्यों को पूरा किया, यह उस मामले का पता लगाने के लिए ग्राहक के लिए सीधा है।

एक अंतिम महत्वपूर्ण पहलू: आप अपने अनुबंध के निर्णय को अपने ग्राहकों तक कैसे पहुंचाते हैं? जैसे जावा में, मैं "doAll ()" या "tryToDoAll ()" जैसे विधि नामों का उपयोग करूंगा। HTTP में, आप तदनुसार समापन बिंदु URL का नाम दे सकते हैं, उम्मीद करते हैं कि आपके क्लाइंट डेवलपर्स ने नामकरण को पढ़ा, और समझ सकते हैं (मैं उस पर दांव नहीं लगाऊंगा)। कम से कम आश्चर्य का अनुबंध चुनने का एक और कारण।

— राल्फ़ क्लेबरहॉफ़
स्रोत

0

उत्तर:

बस प्रति कार्य एक अनुरोध का उपयोग करें, और अतिरिक्त ओवरहेड को स्वीकार करें।

एक स्थिति कोड एक ऑपरेशन की स्थिति का वर्णन करता है। इसलिए, यह अनुरोध के अनुसार एक ऑपरेशन के लिए समझ में आता है।

एकाधिक स्वतंत्र संचालन प्रिंसिपल को तोड़ते हैं जो अनुरोध-प्रतिक्रिया मॉडल और स्थिति कोड पर आधारित होते हैं। तुम प्रकृति से लड़ रहे हो।

HTTP / 1.1 और HTTP / 2 ने HTTP रिक्वेस्ट का ओवरहेड बहुत कम कर दिया है। मेरा अनुमान है कि ऐसी बहुत कम स्थितियाँ हैं जहाँ स्वतंत्र अनुरोधों को सीमित करना उचित हो।

ने कहा कि,

(1) आप पाच अनुरोध ( RFC 5789 ) के साथ कई संशोधन कर सकते हैं । हालाँकि, इसके लिए यह आवश्यक है कि परिवर्तन स्वतंत्र न हों; वे परमाणु (सभी या कुछ भी नहीं) पर लागू होते हैं।

(२) अन्य ने २० 207 मल्टी-स्टेटस कोड बताया है। हालाँकि, इसे केवल HTTP के विस्तार WebDAV ( RFC 4918 ) के लिए परिभाषित किया गया है ।

207 (मल्टी-स्टेटस) स्थिति कोड कई स्वतंत्र संचालनों के लिए स्थिति प्रदान करता है (अधिक जानकारी के लिए धारा 13 देखें)।

...

एक बहु-स्थिति प्रतिक्रिया उन स्थितियों में कई संसाधनों के बारे में जानकारी देती है जहां कई स्थिति कोड उपयुक्त हो सकते हैं। 'मल्टीस्टैटस' रूट [एक्सएमएल] तत्व किसी भी क्रम में शून्य या अधिक 'प्रतिक्रिया' तत्व रखता है, प्रत्येक में एक व्यक्तिगत संसाधन के बारे में जानकारी होती है।

207 WebDAV XML प्रतिसाद एक गैर-WebDAV API में एक बत्तख के समान विषम होगा। यह मत करो।

— पॉल ड्रेपर
स्रोत

1

आप अनिवार्य रूप से यह बता रहे हैं कि @Anders में XY समस्या है । आप सही हो सकते हैं, लेकिन दुर्भाग्य से, इसका मतलब है कि आपने वास्तव में पूछे गए सवाल का जवाब नहीं दिया है (मल्टी-एक्शन रिक्वेस्ट के लिए क्या स्थिति कोड का उपयोग करना है)।

— अजुर्न

2

@Azuaron, बच्चों की पिटाई के लिए किस तरह का बेल्ट सबसे अच्छा काम करता है? मुझे लगता है कि "एन / ए" एक स्वीकार्य जवाब है। इसके अलावा, एंड्रेस ने अपने विचारों की सूची में कई अनुरोध शामिल किए। मैंने उस विकल्प का तहे दिल से समर्थन किया।

— पॉल ड्रेपर

मैंने किसी तरह याद किया कि उसने सूचीबद्ध किया था। उस मामले में, मैं यह एक मूर्खतापूर्ण सवाल है, आपका सम्मान!

— अज़ुर्ऑन

1

@Azuaron मुझे लगता है कि यह एक वैध जवाब है। अगर मैं यह सब गलत कर रहा हूं तो मैं चाहता हूं कि कोई ऐसा कहे, और मुझे यह निर्देश न दें कि मैं एक चट्टान को कैसे चला सकता हूं।

— एंडर्स

1

207 प्रतिक्रिया में JSON भेजने के लिए कुछ भी मना नहीं करता है, जब तक कि सामग्री-प्रकार हेडर ठीक से सेट नहीं होता है और क्लाइंट द्वारा पूछे गए (हेडर स्वीकार करें) से मेल खाता है।

— डोलमेन

0

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

एपीआई का उपयोग करने वाले ग्राहक के रूप में, मैं एक एपीआई कॉल पर पूरी सफलता या विफलता से निपट सकता हूं। आंशिक सफलता से निपटना कठिन है, क्योंकि मुझे सभी संभावित राज्यों को संभालना होगा।

— डीन
स्रोत

2

मुझे लगता है कि यदि अनुरोध परमाणु होना चाहिए तो उसने इस प्रश्न को पोस्ट नहीं किया होगा।

— एंडी

@ और शायद, लेकिन आप यह नहीं मान सकते हैं कि वह इस तरह के डिजाइन के सभी निहितार्थों पर विचार करता है।

— डीन

अनुरोध परमाणु नहीं होना चाहिए - जैसे कि # 2 विफल होने पर, # 1 द्वारा किए गए परिवर्तन अभी भी बने रहना चाहिए। इसलिए एक लेन-देन में सब कुछ लपेटना एक विकल्प नहीं है।

— एंडर्स