खाली टेबल के लिए उचित REST प्रतिक्रिया?


106

चलो आप को फोन करके उपयोगकर्ताओं की सूची प्राप्त करना चाहते हैं कहते हैं कि GETकरने के लिए api/users, लेकिन वर्तमान में मेज छोटा कर दिया गया कोई उपयोगकर्ता नहीं है तो। इस परिदृश्य के लिए उचित प्रतिक्रिया क्या है: 404या 204?


19
मैं 200 और एक खाली संग्रह के साथ प्रतिक्रिया करना चाहूंगा (खाली प्रतिक्रिया निकाय नहीं, बल्कि अंदर कोई तत्व नहीं है, यह प्रारूप के आधार पर अलग दिखेगा)
toniedzwiedz

4
इस संदर्भ में ४०४ शायद 'तालिका नहीं मिली' के लिए बेहतर अनुकूल होगा। मैं कहूंगा कि एक खाली सूची लौटाएं।
माता


2
@EJoshuaS यह नहीं है। दोनों प्रश्न मेरे और बहुत पुराने हैं। वे समान हैं लेकिन डुप्लिकेट नहीं हैं।
आईएमबी

1
@EJoshuaS वे स्पष्ट रूप से डुप्लिकेट नहीं हैं। यह सवाल उस बारे में है, /api/usersजबकि एक के बारे में है /api/users/1
फ्रैंकलिन यू

जवाबों:


231

मैं कहूंगा, न।

404 क्यों नहीं (नहीं मिला)?

404 स्थिति कोड स्थितियों के लिए आरक्षित होना चाहिए, जिसमें एक संसाधन नहीं मिला है। इस स्थिति में, आपका संसाधन उपयोगकर्ताओं का एक संग्रह है । यह संग्रह मौजूद है, लेकिन वर्तमान में यह खाली है। व्यक्तिगत रूप से, मैं आपके आवेदन के लिए एक ग्राहक के लेखक के रूप में बहुत भ्रमित होऊंगा यदि मुझे 200एक दिन और 404अगले दिन सिर्फ इसलिए मिला क्योंकि कोई एक उपयोगकर्ता को निकालने के लिए हुआ था। मुझे क्या करना चाहिए? क्या मेरा URL गलत है? क्या किसी ने एपीआई को बदल दिया और एक पुनर्निर्देशन छोड़ने की उपेक्षा की।

204 (कोई सामग्री) क्यों नहीं?

यहाँ w3c द्वारा 204 स्थिति कोड के विवरण का एक अंश दिया गया है

सर्वर ने अनुरोध पूरा कर लिया है, लेकिन उसे निकाय-निकाय को वापस करने की आवश्यकता नहीं है, और अद्यतन मेटैनफॉर्मेशन वापस करना चाह सकता है।

हालांकि यह इस मामले में उचित लग सकता है, मुझे लगता है कि यह ग्राहकों को भ्रमित भी करेगा। A 204यह संकेत देता है कि कुछ ऑपरेशन को सफलतापूर्वक निष्पादित किया गया था और किसी भी डेटा को वापस करने की आवश्यकता नहीं है। यह एक DELETEअनुरोध के जवाब के रूप में या शायद कुछ स्क्रिप्ट को फायर करने के लिए एकदम सही है जिसे डेटा वापस करने की आवश्यकता नहीं है। आपके मामले में api/users, आप आमतौर पर उपयोगकर्ताओं के अपने संग्रह का प्रतिनिधित्व प्राप्त करने की अपेक्षा करते हैं। एक प्रतिक्रिया निकाय को एक बार भेजना और दूसरी बार नहीं भेजना असंगत और संभावित रूप से भ्रामक है।

मैं 200 का उपयोग क्यों करूँगा (ठीक है)

उपरोक्त कारणों (संगतता) के लिए, मैं एक खाली संग्रह का प्रतिनिधित्व लौटाऊंगा। मान लें कि आप XML का उपयोग कर रहे हैं। उपयोगकर्ताओं के एक गैर-खाली संग्रह के लिए एक सामान्य प्रतिक्रिया निकाय इस तरह दिख सकता है:

<users>
  <user>
    <id>1</id>
    <name>Tom</name>
  </user>
  <user>
    <id>2</id>
    <name>IMB</name>
  </user>
</users>

और यदि सूची खाली है, तो आप बस कुछ इस तरह से जवाब दे सकते हैं (जबकि अभी भी एक 200):

<users/>

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

आप JSON या HTML या जो भी प्रारूप आप उपयोग कर रहे हैं, वही कर सकते हैं।


4
निश्चित रूप से सहमत हैं। और आरईएसटी के लिए, मैं बस एक खाली सरणी के साथ 200 का एक स्टेटस कोड वापस भेजूंगा []:।
चाड जॉनसन

समझ में आता है। इसे कठिन बनाने की जरूरत नहीं है। 404 भ्रामक होगा।
विटोल्ड काकज़ुरबा

यह मान लें कि एपीआई जो आपकी जेब में मौजूद सिक्कों का वर्णन करता है, एंडपॉइंट के साथ: GET /singleCoin- आपकी जेब से यादृच्छिक एकल सिक्का GET /severalCoinsलौटाता है , - आपकी जेब से कुछ सिक्के लौटाता है जिन्हें आप एक समय में हड़प सकते हैं। कहते हैं कि अब आपकी जेब में कोई सिक्का नहीं है। जब आप करने के लिए कह GET /singleCoinआप मिल जाएगा 404 Not Found, लेकिन जब आप के लिए पूछना GET /severalCoinsआप मिल जाएगा 200 OKरिक्त सूची से []। एक तथ्य - आपके पास कोई सिक्के नहीं हैं, विभिन्न प्रतिक्रियाओं के साथ वर्णित है, क्यों? मैं कहता हूं कि यह हमेशा प्राप्त करना बेहतर होता है 404 Not Found, क्योंकि आपकी जेब में कोई सिक्के नहीं पाए जाते हैं।
सेम्पाशा

1
@ सेमाशा यह इस बात पर निर्भर करता है कि आप क्या मतलब रखते हैं GET /severalCoins। यदि आप जनादेश देते हैं कि कुछ सिक्के वापस GET /severalCoins करना चाहिए तो यह 200 नहीं होना चाहिए क्योंकि यह ठीक नहीं है; क्लाइंट क्या चाहते हैं प्रदान करने में विफल। के लिए /singleCoinयह स्पष्ट है क्योंकि क्लाइंट ठीक एक सिक्का, कोई और अधिक, कम नहीं चाहते हैं। यह उसी के लिए है /coins/7/coinsसमापन बिंदु के विपरीत , आमतौर पर ग्राहक कोई सिक्का, एक सिक्का या कई सिक्कों की अपेक्षा नहीं करते हैं। उन सभी की वैध प्रतिक्रिया है। यदि कोई सिक्का नहीं है, तो यह वही है जो वे चाहते हैं। यह List<Coin>जावा के बजाय एक साम्राज्य की तरह है null
फ्रेंकलिन यू

15

मैं रनटाइम स्थिति के आधार पर दो में से एक कोड का जवाब दूंगा:

404 नहीं मिला)

यदि आपके पास कोई तालिका नहीं है, तो यह उत्तर बहुत सही है। न सिर्फ खाली टेबल बल्कि नो USER टेबल। यह सटीक विचार की पुष्टि करता है - कोई संसाधन नहीं। अधिक विकल्प अधिक विवरण प्रदान करने के लिए हैं। आपकी तालिका अनुपस्थित क्यों है, अधिक विस्तृत कोडों के जोड़े हैं, लेकिन 404 उस स्थिति को संदर्भित करने के लिए बहुत अच्छा है जहां आपके पास वास्तव में कोई तालिका नहीं है।

200 (ठीक है)

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


10

यदि आप उपयोगकर्ता ऑब्जेक्ट की सूची की उम्मीद कर रहे हैं, तो सबसे अच्छा समाधान 404 या 204 प्रतिक्रिया का उपयोग करके 200 ओके के साथ एक खाली सूची ([]) वापस कर रहा है।


2

निश्चित रूप से 200 लौटाता है।

404 का अर्थ है संसाधन नहीं मिला। लेकिन संसाधन मौजूद है। और यह भी, अगर प्रतिक्रिया में 404 की स्थिति है। आप कैसे जान सकते हैं कि उपयोगकर्ता खाली या भरे हुए हैं?


  • '/ यूजर्स' खाली होने पर '200' वापस करना चाहिए।
  • आईडी नहीं मिलने पर '/ यूजर्स / 1'। 404 लौटाना चाहिए।

2

यह खाली सूची के साथ 200 ठीक होना चाहिए ।

क्यों: खाली तालिका का मतलब है कि तालिका मौजूद है लेकिन कोई रिकॉर्ड नहीं है।

404 Not Found का अर्थ है अनुरोधित अंतिम बिंदु मौजूद नहीं है।

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.