क्या "कोई परिणाम नहीं" एक उत्साहपूर्ण प्रतिक्रिया में एक त्रुटि होना चाहिए?

52

मैं एक उदाहरण का वर्णन करूंगा:
मैं एक बेकिंग शॉप के लिए एपीआई बनाना शुरू करता हूं। एपीआई लोगों को बेकिंग उत्पादों के लिए अपने कैटलॉग को खोजने की अनुमति देगा, जैसे कि घर का बना मिन्टी चॉकलेट चिप कुकीज़ का उपयोग करना api.examplebakery.com/search?q=.....।

कोई इसका उपयोग किसी उत्पाद को देखने के लिए करता है pineapple-banana flavoured cookiesऔर जाहिर है कि इसका कोई परिणाम नहीं मिलेगा।

क्या इसे त्रुटि के रूप में लौटाया जाना चाहिए? खोज विफल नहीं हुई, एपीआई ने खोज की और सफलतापूर्वक निष्कर्ष निकाला कि कोई कुकीज़ नहीं मिल सकती है। एपीआई वापस नहीं आना चाहिए 404, क्योंकि एपीआई वास्तव में पाया गया था।

rest http-response

— बेरी एम।
स्रोत

51

204 कोई सामग्री नहीं

— आकाशवाणी

6

रेस्टफुल एपीआई के

— gnat

3

@gnat: यह कोई डुप्लिकेट नहीं है, क्योंकि दूसरा सवाल एक विशिष्ट संसाधन के बारे में है, न कि कई संसाधनों के खिलाफ क्वेरी।

— ग्रेग बर्गार्ड्ट

7

एनालॉग रूप से, मान लें कि आपके पास एक फ़ंक्शन है जो ऑब्जेक्ट की एक सरणी देता है। यदि कोई ऐसी वस्तुएं नहीं हैं जो एक विशेष उपयोग के मामले से मेल खाती हैं, तो क्या आप एक अपवाद के माध्यम से कार्य करेंगे या एक खाली सरणी लौटाएंगे?

— केविन -

2

@ Gash अनुरोध पर HTTP-204 को वापस करना काफी असामान्य है, मुझे पता है कि मैंने ऐसा कहीं नहीं देखा है। जहाँ तक मुझे पता है, HTTP-204 का उपयोग आमतौर पर सर्वर के संसाधन को संशोधित करते समय प्रतिक्रिया के रूप में किया जाता है, उदाहरण के लिए POST / PUT / DELETE अनुरोध।

— रादु मुरझिया

122

जब परिणाम होते हैं, तो आउटपुट एक (JSON, आपकी टिप्पणी के आधार पर) सूची है। बिना परिणाम वाले प्रश्नों के लिए, आउटपुट बिल्कुल समान होना चाहिए। सरल सूची में 0 आइटम हैं।

तो अगर आपकी प्रतिक्रिया सामान्य रूप से यह है:

{
    "results": [
        {
            "name": "Pancakes",
            ....
        },
        {
            "name": "French Fries",
            ....
        }
    ]
}

फिर 0 परिणामों वाली क्वेरी के लिए, यह ऐसा होना चाहिए:

{
    "results": []
}

यदि आप मेटा डेटा को परिणामों के कितने "पृष्ठ" शामिल करते हैं, तो उन "पृष्ठों", आदि के लिंक भी शामिल हैं, तो मेरा सुझाव है कि 1 "पृष्ठ" है।

HTTP स्थिति के रूप में जब वहाँ परिणाम हैं एक ही होना चाहिए - 200 OK।

204 No Contentएक विकल्प भी प्रतीत हो सकता है, लेकिन ऐसा नहीं है क्योंकि आप वास्तव में "सामग्री" वापस कर रहे हैं - खाली सूची। यदि आपको लगता है कि खाली सूची को "सामग्री" के रूप में नहीं गिना जाता है, तो क्या होगा यदि आप वर्तनी सुझावों की पेशकश की प्रतिक्रिया में संशोधन करते हैं? प्रतिक्रिया का मूल अभी भी एक खाली सूची होगी, लेकिन अब और भी "सामग्री" है।

HTTP स्थिति कोड के बारे में अधिक उपयोगी जानकारी के लिए, jpmc26 उनका उत्तर पढ़ने योग्य है।

— जरी जियारतें
स्रोत

9

यह उसी तरह की सोच है जैसे अशक्त वस्तु पैटर्न । त्रुटियां और अशक्तता यह कहने का एकमात्र तरीका नहीं है कि यहां कुछ भी नहीं है। कभी-कभी आप अपने कुछ भी चुपचाप व्यक्त नहीं करना चाहते हैं। इस तरह से ग्राहकों को कुछ नहीं के लिए परीक्षण नहीं करना है।

— कैंडिड_ऑरेंज सेप

54

मेरा तर्क है कि 204 लौटाना अनुचित है, क्योंकि आप सामग्री वापस कर रहे हैं। यह सिर्फ इतना है कि सामग्री का कोई परिणाम नहीं है, जो किसी भी सामग्री को वापस करने से अलग है।

— TMN

9

@TMN सहमत - 204 "कोई परिणाम नहीं" के लिए उपयुक्त नहीं है। आपकी क्वेरी को हमेशा सरणी के अंदर परिणामों के साथ, एक सरणी वापस करनी चाहिए। यदि कोई परिणाम नहीं हैं, तो ग्राहक स्वाभाविक रूप से संभाल लेंगे। यदि ग्राहक विशेष पाठ ("कोई परिणाम नहीं मिला") दिखाना चाहता है, तो यह ठीक है। 204 को केवल एक समापन बिंदु के लिए लौटाया जाना चाहिए जो स्वाभाविक रूप से परिणाम नहीं देता है।

— जेसन

1

आप 204 का उपयोग कर सकते हैं यदि आप रिक्त स्ट्रिंग के रूप में निरर्थक लौट रहे हैं जो मैं पुन

— बनाता

15

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

— गुरन

37

जब भी आप HTTP कोड का निर्णय लेते हैं, तो आपको हमेशा यह प्रश्न पूछना चाहिए:

प्रतिक्रिया के साथ कोई भी मनमाना ग्राहक क्या कर सकता है / कर सकता है?

क्या ग्राहक को हमेशा प्रतिक्रिया को विफलता के रूप में मानना चाहिए? फिर आप 4xx या 5xx चाहते हैं, इस पर निर्भर करता है कि समस्या क्लाइंट के इनपुट की है या सर्वर की प्रक्रियाओं की है।
क्या ग्राहक को इसके बजाय कहीं और अनुरोध करना चाहिए? फिर 3xx आपके लिए है।
क्या सर्वर ने क्लाइंट से पूछा (सफल) किया? वह 2xx है।

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

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

अब सवाल है, "कौन सा 2xx?" यह इस बात पर निर्भर करता है कि आप सर्वर का जवाब देने के लिए क्या चाहते हैं।

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

अन्य बिल्कुल लागू नहीं हैं:

201 प्रश्न से बाहर है। आपने कोई लगातार संसाधन नहीं बनाए हैं और किसी बनाए गए संसाधन के लिए स्थान नहीं लौटा रहे हैं।
202 प्रश्न से बाहर है। निवेदन किया जाता है; यह पृष्ठभूमि में प्रसंस्करण नहीं कर रहा है।
203 का अर्थ है कि प्रतिक्रिया को आधिकारिक सर्वर और क्लाइंट के बीच संशोधित किया गया था। आपका RESTful इंटरफेस है , आधिकारिक सर्वर तो यह यहाँ लागू नहीं होता।
205 का कोई मतलब नहीं है। आपको क्लाइंट को कुछ भी साफ़ करने या ताज़ा करने की आवश्यकता नहीं है।
206 कई प्रतिक्रियाओं पर एक बड़े संसाधन को लौटाने के लिए डिज़ाइन किया गया है। इसके लिए यह भी आवश्यक है कि क्लाइंट हेडर में सामग्री का एक हिस्सा मांगे (इसलिए क्वेरी स्ट्रिंग्स के माध्यम से अंकन योग्य नहीं है)। यहां लागू नहीं है।

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

— jpmc26
स्रोत

5

डाउनवॉटर की राय में रुचि होगी। मुझे नहीं लगता कि इसमें से कोई भी विवादास्पद है।

— jpmc26

2

मुझे नहीं लगता कि ग्राहकों को 204 के लिए स्पष्ट रूप से जांचना होगा। वे सभी की जरूरत है अशक्त प्रतिक्रिया वस्तु को संभालने की क्षमता है। यह "शरीर को पार्स" भाग को छोड़कर 204 को संभालने के लिए HTTP फ्रेमवर्क का काम है। कंटेंट-लेंथ 4 और बॉडी नल के साथ 200 बस एक ही है।

— Agent_L

1

@Agent_L आप सही हैं कि यदि सर्वर सामान्य प्रतिक्रिया के साथ असंगत संरचना के साथ प्रतिक्रिया करता है (जैसे nullकि जहां सामान्य रूप से सूची है), तो आप 200 के साथ भी निरंतरता के लाभों को वापस नहीं लेंगे। हालांकि, मैं जो वर्णन करता हूं वह एक का उपयोग कर रहा है प्रतिक्रिया जो सामान्य संरचना के अनुरूप है और एक खाली सूची है जहां परिणामों की सूची सामान्य रूप से जाएगी। 204 किसी भी अवसर को ऐसी निरंतर प्रतिक्रिया के लिए दूर ले जाता है। इसके अलावा, HTTP क्लाइंट पुस्तकालयों में भी, जहां इसके लिए सुविधा कार्य हैं, आपको अक्सर (आमतौर पर) JSON को पार्स करने के लिए एक स्पष्ट कॉल करना होगा।

— jpmc26

@Agent_L विशेष रूप से सूचियों के साथ, कॉल करने वाले अक्सर अपने कोड को सामान्य रूप से एक खाली सूची (उदाहरण के लिए, इस पर लूप करके) चला सकते हैं, जबकि उन्हें किसी अन्य प्रकार के प्रतिनिधित्व को संभालने के लिए किसी प्रकार की स्पष्ट जाँच की आवश्यकता होगी।

— jpmc26

16

सं। 404 का उपयोग यह दर्शाने के लिए कि 'आपकी क्वेरी संसाधित हो गई थी लेकिन मैच नहीं थे' भयानक है क्योंकि:

अपवाद संचालन पर आधारित सशर्त प्रवाह (यानी ग्राहक में एक अपवाद को बनाने और संभालने के लिए एक गैर-असाधारण परिणाम के लिए मजबूर करना जो गैर निष्पादित और अजीब हो सकता है)
'वास्तविक' पृष्ठ के बीच अस्पष्टता नहीं मिली, आपने अंतिम त्रुटि गलत टाइप की

याद रखने वाली बात यह है कि संदेश को डिसेर्बलाइज करने के लिए हमेशा एक क्लाइंट होता है और इसके क्लाइंट के लिए यह महत्वपूर्ण होता है; क्रमबद्धता नहीं।

यदि ग्राहक को अशक्त लौटना चाहिए, तो अशक्तता के क्रमांकन का उपयोग करें। यदि क्लाइंट को खाली सरणी वापस करनी चाहिए, तो [] का उपयोग करें, यदि क्लाइंट को त्रुटि का उपयोग 500 फेंकना चाहिए और त्रुटि संदेश पास करना चाहिए

— ईवान
स्रोत

2

ग्राहक की जानकारी के साथ सर्वर क्या कर रहा है, इसकी परवाह क्यों करनी चाहिए? (पुनश्च: मैं ऐसा नहीं हूं जिसने आपके उत्तर को अस्वीकार कर दिया हो)।

— राडू मुरझिया

इस संदर्भ में 'क्लाइंट' क्लाइंट डिवाइस पर चलने वाला कोड है जो क्लाइंट एप्लिकेशन को सेवा को उजागर करता है। इसे सेवाओं के तरीकों को उजागर करने में सक्षम होना चाहिए और सेवा के अनुसार परिणामों को वापस करना होगा। संचार के लिए आपको एक क्लाइंट-सर्वर जोड़ी की आवश्यकता है

— ईवान

3

ग्राहक त्रुटियों के लिए 5xx का प्रयोग न करें , अवश्य करें। उस स्थिति में 4xx को प्राथमिकता दें।

— केविन

1

हालाँकि, यह "सर्वर" नहीं होना चाहिए, न कि इन उदाहरणों में "क्लाइंट"? यह सर्वर है जो अनुरोध को संसाधित कर रहा है और प्रतिक्रिया दे रहा है, ग्राहक सिर्फ प्रतिक्रिया की प्रक्रिया करता है? किस स्थिति में एक 5xx कोड ठीक होगा, क्योंकि यह एक सर्वर त्रुटि है, क्लाइंट त्रुटि नहीं?

— MrWhite

2

सभी त्रुटि कोडों के साथ परेशानी यह है कि उनका http के भीतर अर्थ है। 500 एकमात्र कोड है जो आपकी सेवा के अपवाद के लिए उपयुक्त है

— इवान

9

परे @ इवान का बहुत अच्छा जवाब:

यदि क्वेरी वह प्रकार है जो परिणामों का एक सेट लौटाता है, तो खाली सेट तार्किक रूप से केवल एक सेट या अधिक के सेट के रूप में उपयुक्त है। आम तौर पर @Ewan के कारणों के लिए बोलते हुए, यह खाली सेट को एक त्रुटि में बदलने के लिए अच्छे से अधिक नुकसान करता है, और, यह केवल अनावश्यक है।

यदि क्वेरी वह प्रकार है जो एक विशिष्ट सिंगलटन को देखता है और वापस करता है (जो कि मिलने की उम्मीद है, जैसे आईडी द्वारा सटीक मिलान), तो नहीं मिला यह एक तार्किक रूप से उपयुक्त संभव प्रतिक्रिया है।

— एरिक Eidt
स्रोत

हाँ, मैंने बिल्कुल सोचा कि इवान के जवाब पर।

— वालफ्रैट

5

आप मान रहे हैं कि कोई डेटा वापस नहीं आने पर कोड को एक विशेष कार्रवाई करनी होगी, लेकिन ऐसा नहीं हो सकता है। कोड केवल एक उत्पाद की गणना के लिए, या किसी सूची या किसी भी संख्या में परिणामों को जोड़कर देखा जा सकता है। यदि वास्तव में कोई त्रुटि है तो आपको केवल एक उपयोगकर्ता को "त्रुटि" देनी चाहिए।

— जॉन स्मिथ
स्रोत

3

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

— मृद्वीप २ '’१

0

जब मैं एक एपीआई का उपयोग करता हूं, तो एक ग्राहक के रूप में मुझे "त्रुटि" मामलों को "त्रुटि" मामलों से अलग करना होगा; मेरे पास वहां कोई विकल्प नहीं है। इसलिए, आपको उन स्थितियों में एक त्रुटि वापस करनी चाहिए जो ग्राहक अलग तरीके से व्यवहार करना चाहता है, और उन परिस्थितियों में सफलता जो ग्राहक उसी का इलाज करना चाहते हैं ।

यदि मैं एक क्वेरी करता हूं जो सिद्धांत में किसी भी संख्या में परिणाम, शून्य, एक, दो सौ और इतने पर वापस कर सकता है, तो आपको "सफलता" वापस करना चाहिए जब भी एपीआई सभी परिणामों की पूरी सूची वितरित करता है। और संभवतः ऐसे मामलों में जहां कई परिणाम होते हैं, आपने अत्यधिक आकार से बचने के लिए परिणामों की एक आंशिक सूची वापस कर दी, और एक सहमत तरीका है कि मुझे अन्य परिणाम कैसे प्राप्त होंगे। ऐसा इसलिए है क्योंकि एक ग्राहक के रूप में, मैं अक्सर अधिक परिणामों के मामले की तरह शून्य परिणामों के मामले को संभालना चाहता हूं। मैं इसे अलग तरह से समझ सकता हूं, लेकिन मैं मजबूर नहीं होना चाहता।

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

सारांश: यदि ग्राहक शून्य से बड़ी संख्या तक किसी भी परिणाम की उम्मीद करता है, तो "सफलता" लौटाएं यदि सभी परिणाम वितरित किए जाते हैं, भले ही संख्या शून्य हो। यदि क्लाइंट को ठीक एक परिणाम की उम्मीद है, तो परिणाम मिलने पर सफलता लौटाएं, और यदि परिणाम नहीं मिला तो त्रुटि।

— gnasher729
स्रोत