उत्कृष्ट एपीआई डिजाइन। यदि कोई पंक्तियाँ नहीं हैं तो मुझे क्या करना चाहिए?

Question

मैं वर्तमान में स्लिम फ्रेमवर्क के साथ सामाजिक नेटवर्क के लिए एक एपीआई कोडिंग कर रहा हूं। मेरा प्रश्न है: जब जसन संरचना में लौटने के लिए कोई पंक्तियाँ नहीं हैं तो सबसे अच्छी प्रथाएँ क्या हैं?

आइए बताते हैं कि यह कॉल / v1 / get / Movies टेबल मूवी के नामों से 2 पंक्तियाँ लौटाती है:

[
    {"name": "Ghostbusters"},
    {"name": "Indiana Jones"}
]

लेकिन, तब मैं / v1 / get / किताबें कॉल करता हूं और उस तालिका में कोई पंक्तियाँ नहीं हैं। क्या मुझे सिर्फ एक खाली ढांचा लौटाना चाहिए?

[
]

... या यह एक संदेश और एक त्रुटि कोड बेहतर होगा?

[
    "errors": {
        "message": "no matches found",
        "code": 134
    }
]

कौन सा बेहतर अभ्यास है? (iOS और Android ऐप्स में API का उपयोग किया जाएगा) धन्यवाद!

Comments

मेरे लिए यह इस सवाल की तरह है कि क्या शून्य वास्तव में एक राशि है।

— स्कारफ्रिज

आपका उदाहरण टूट गया है। आपके पास डुप्लिकेट कुंजियों के साथ एक जोंस ऑब्जेक्ट नहीं हो सकता है। आप जो देख रहे हैं वह एक सरणी है, जिसका अर्थ है[{"name": "..."}, {"name":"..."}]

— मार्टिन विकमैन

@MartinWickman इसके लिए क्षमा करें, मैंने अभी इसे ठीक किया है।

— एंड्रेस एसके

@andufo, वास्तव में, आपने नहीं किया ...

— avakar

यदि आपका आवेदन RESTful माना जाता है, तो क्रिया / विधि को "आपके समापन बिंदु URI का एक हिस्सा" क्यों मिलता है?

— user50849

Answer 1

आमतौर पर मैं मेटाडाटा के रूप में परिणाम में रिकॉर्ड की संख्या वापस आ जाएगी। मुझे यकीन नहीं है कि यह सामान्य रीस्ट अभ्यास है, लेकिन यह बहुत अतिरिक्त डेटा नहीं है, और यह बहुत सटीक है। आमतौर पर बहुत सारी सेवाओं के लिए पेजिनेशन होता है, एक ही बार में भारी परिणाम लौटना अव्यावहारिक है। व्यक्तिगत रूप से जब छोटे परिणाम सेट के लिए पृष्ठ पर अंक लगाना होता है, तो मुझे गुस्सा आता है .. यदि यह खाली है, तो number_of_records : 0खाली सूची / सरणी के रूप में पुस्तकें वापस करें books : []।

{
    meta: {
        number_of_records : 2,
        records_per_page : 10,
        page : 0
    },
    books : [
        {id:1},
        {id:27}
    ]
}

EDIT (कुछ साल बाद): मार्टिन विकमैन का उत्तर बहुत बेहतर है, यहाँ स्पष्टीकरण की "संक्षिप्त" वजह है।

जब अंकुरण के साथ काम करना हमेशा सामग्री या ऑर्डर बदलने की संभावना को ध्यान में रखता है। जैसे, पहला अनुरोध आता है, 24 परिणाम, आप पहले 10. वापस आते हैं। उसके बाद, "नई पुस्तक" डाली जाती है और अब आपके पास 25 परिणाम हैं, लेकिन मूल अनुरोध के साथ यह 10 वें स्थान पर आ जाएगा। जब पहला उपयोगकर्ता 2 पेज का अनुरोध करता है, तो उसे "नई पुस्तक" नहीं मिलेगी। ऐसी समस्याओं को संभालने के तरीके हैं, जैसे "अनुरोध आईडी" प्रदान करना जिसे निम्नलिखित एपीआई कॉल के साथ भेजा जाना चाहिए, फिर अगले पृष्ठ पर "पुराने" परिणाम सेट से लौटना चाहिए, जिसे किसी तरह संग्रहीत किया जाना चाहिए और "अनुरोध आईडी" से बंधा होना चाहिए। वैकल्पिक "पहले अनुरोध के बाद से बदल दी गई परिणाम सूची" जैसे फ़ील्ड को जोड़ना है।

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

यदि आपके पास एक साथ संसाधित करने के लिए बहुत अधिक डेटा है , तो उस सूची के कुछ भाग के लिए सभी परिणामों और विवरणों के साथ "आईडी सूची" वापस करने पर विचार करें, और संसाधन के लिए बहु_get / get_by_id_list एपीआई कॉल प्रदान करें।

Comments

हुह, मुझे आश्चर्य है कि क्यों इस एक दूसरे के रूप में अत्यधिक वोट नहीं दिया है। मुझे यह अधिक पसंद है क्योंकि यह दोनों एक खाली सूची दे रहा है (जो कि एक सूची होना चाहिए था, ठीक है?) कि आप विशेष परिस्थितियों के बिना नेत्रहीन रूप से पुनरावृति कर सकते हैं, लेकिन मेटाडेटा गिनती भी कहने के तरीके के रूप में है, "नहीं, हमने नहीं किया था ' t आपके लिए एक त्रुटि है, वास्तव में 0 परिणाम थे "।

— इज़्काता

-1 क्योंकि booksपैरामीटर एक ऑब्जेक्ट है लेकिन 'बुक्स' का मतलब एक से अधिक है और एक से अधिक का मतलब सरणी से है। मेटा डेटा शांत और सभी है, लेकिन अंततः मुझे किताबों के संग्रह में किताबों की एक सूची होने की उम्मीद होगी; अगर कोई किताबें नहीं हैं तो मुझे सिर्फ खाली सरणी दें

— चार्ल्स स्प्रेबेरी

इसके साथ समस्या यह है कि "number_of_records" को जोड़ने से कोई अधिक जानकारी नहीं मिलती है, यह सिर्फ अतिरेक जोड़ता है और जटिलता बढ़ाता है। एक त्रुटि को इंगित करने के लिए, शरीर में एक उपयुक्त http कोड + कुछ वापस करें।

— मार्टिन विकमैन

@ इस्क्रा की सूची में लिस्ट है, जैसा कि इज़कट ने बताया, मेरी टाइपो।

— ग्रीजवको

@MartinWickman मैं अतिरिक्त मेटाडेटा के साथ मूल उत्तर को प्रदूषित नहीं करना चाहता था, लेकिन मेरे अनुभव में, बहुत सारी सेवाएं सीधे सभी डेटा वापस नहीं करती हैं, लेकिन "पृष्ठबद्ध" तरीके से।

— ग्रिजवाको

Answer 2

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

 [
    {"name": "movie1"}, 
    {"name": "movie2"}
 ]

यह दृष्टिकोण आपके प्रश्न का उत्तर भी देता है। जब क्वेरी मेल नहीं खाती है , तो आपको एक खाली सरणी वापस करना चाहिए :

[]

दूसरी ओर, यदि आप एक विशिष्ट फिल्म संसाधन प्राप्त करने का प्रयास करते हैं GET api/movie/34और वह फिल्म मौजूद नहीं है, तो 404 को एक उपयुक्त (json एन्कोडेड) त्रुटि संदेश के साथ वापस करें

Comments

+1 यह मान्य JSON के अनुसार है json_xs।

— l0b0

Answer 3

यदि यह JSON है, तो आपको वास्तव में वस्तुओं का एक सरणी वापस करने पर विचार करना चाहिए। इसके कई फायदे हैं, जब आपके पास कोई रिकॉर्ड नहीं है तो यह एक खाली सरणी है।

इसलिए जब आपके पास रिकॉर्ड होगा, तो आप वापस आ जाएंगे:

    [
        {"name": "Ghostbusters"},
        {"name": "Indiana Jones"}
    ]

और जब आपके पास कोई रिकॉर्ड नहीं है, तो आप वापस आ जाएंगे:

    [

    ]

Answer 4

यदि आप ऑपरेशन को सफलतापूर्वक अंजाम देते हैं, लेकिन उसके पास लौटने के लिए कुछ भी नहीं है, जैसे कि खाली नक्शा {}या खाली सरणी []मैं 204 प्रतिक्रिया कोड के साथ जवाब देना पसंद करूंगा, यहां HTTP स्थिति कोड परिभाषाओं का अंश दिया गया है :

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

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

204 प्रतिक्रिया में एक संदेश-निकाय शामिल नहीं होना चाहिए, और इस तरह हेडर फ़ील्ड के बाद हमेशा पहली खाली पंक्ति द्वारा समाप्त किया जाता है।

अनिवार्य रूप से, मैं HTTP पर Restful अनुप्रयोगों में 204 का उपयोग करने की सलाह देता हूं जब लौटने के लिए कुछ भी नहीं होता है।

Comments

मैं यहाँ अन्य उत्तर पर @ अवकर की टिप्पणी से सहमत हूँ। यदि क्लाइंट की कोशिश है कि वह / v1 / पाने / फिल्में / 1 प्राप्त करे तो उसे 404 वापस करना चाहिए, यदि कोई फिल्म 1. पहचानने योग्य नहीं है। बस / v1 / पाने / फिल्मों को 200 वापस करना चाहिए, भले ही कोई फिल्म न हो। लेकिन 204 उपयुक्त नहीं है क्योंकि यह इनपुट क्रियाओं के लिए है।

— imel96

इस समाधान के साथ एक और समस्या यह है कि इसे आम तौर पर क्लाइंट में विशेष कोड की आवश्यकता होगी: यदि प्रतिक्रिया एक खाली सूची है, तो इसे सामान्य प्रतिक्रिया की तरह ही JSON के रूप में पार्स किया जा सकता है। यदि प्रतिक्रिया एक खाली निकाय है, तो JSON पार्सर शिकायत करेगा (क्योंकि एक एमटीपी दस्तावेज़ वैध JSON नहीं है), इसलिए क्लाइंट को HTTP 204 की जाँच करने और पार्सिंग को छोड़ने के लिए अतिरिक्त कोड की आवश्यकता है।

— 12

मेरा मानना ​​है कि यह 204 के इरादे का गलत अर्थ है। 204 ऐसे कार्यों के संचालन के लिए अभिप्रेरित है जो अपेक्षित सामग्री के लिए नहीं है और किसी भी को खोजने में विफल रहे हैं, बल्कि उन कार्यों के लिए जो सफल थे और जिनका कोई इरादा नहीं है । विकिपीडिया से: "सर्वर ने अनुरोध को सफलतापूर्वक संसाधित किया, लेकिन कोई सामग्री वापस नहीं कर रहा है। आमतौर पर एक सफल डिलीट अनुरोध के जवाब के रूप में उपयोग किया जाता है।"

— एक्सएमएल

Answer 5

एक मानकीकृत JSON API प्रारूप बनाने पर उचित मात्रा में काम किया गया है ।

उस विनिर्देश में सिद्धांतों का पालन करने का मतलब है कि लौटे सभी संसाधनों को प्रभावी रूप से "संग्रह" होना चाहिए (तब भी जब केवल एक संसाधन शामिल हो)। इसका मतलब यह होगा कि आपका कॉल /v1/get/moviesवापस आएगा:

{
    "movies": [
        {"name": "Ghostbusters"},
        {"name": "Indiana Jones"}
    ]
}

आपका कॉल /v1/get/books(जो शून्य संसाधन देता है) वापस आ जाएगा:

{
    "books": []
}

Answer 6

आपके विशिष्ट उदाहरण के लिए, मैं सुझाव दूंगा कि / v1 / पाने / पुस्तकों को खाली सरणी के साथ HTTP 200 वापस करना चाहिए।

अगर मैं आपकी पोस्ट को सही से पढ़ रहा हूं, तो आपका API पुस्तकों को इकट्ठा करने का इरादा रखता है। रूपक के अनुसार, आपके पास पुस्तकों के लिए एक बुकशेल्फ़, फिल्मों के लिए एक डीवीडी रैक, और संभवतः अन्य कंटेनर हैं जिनका आपने यहां उल्लेख नहीं किया है। क्योंकि आप किताबें इकट्ठा करने का इरादा रखते हैं, / v1 / पाने / किताबें आपका बुकशेल्फ़ है। इसका मतलब यह है कि पुस्तकों की एक वैध संसाधन -a सूची है- जो आपके विशिष्ट उदाहरण में रिक्त होने के लिए होती है।

इस मामले में HTTP 404 को वापस करने का सुझाव नहीं देने का कारण यह है कि बुकशेल्फ़ अभी भी है। फिलहाल इस पर कोई किताबें नहीं हैं, लेकिन यह अभी भी एक बुकशेल्फ़ है। यदि यह एक बुकशेल्फ़ नहीं थे, तो उदाहरण के लिए एपीआई ने किताबें इकट्ठा करने का इरादा नहीं किया था, तो HTTP 404 उपयुक्त होगा। लेकिन क्योंकि वहां एक संसाधन है, तो आपको यह संकेत नहीं देना चाहिए कि कोई ऐसा नहीं है, जो HTTP 404 करता है। इसलिए, मेरा तर्क है कि एक खाली सरणी (संग्रह को इंगित करने) के साथ 200 अधिक उपयुक्त है।

HTTP 204 को वापस नहीं करने का कारण यह है कि यह सुझाव देगा कि "कोई सामग्री नहीं" सामान्य स्थिति है: इस संसाधन पर इस क्रिया को करने से सामान्य रूप से कुछ भी वापस नहीं होगा। इसलिए इसे आमतौर पर DELETE अनुरोधों की प्रतिक्रिया के रूप में उपयोग किया जाता है, उदाहरण के लिए: हटाने की प्रकृति का आम तौर पर मतलब है कि वापस लौटने के लिए कुछ भी नहीं है। मामला समान है जब इसका उपयोग हेडर के इफ-संशोधित परिवार के अनुरोधों का जवाब देने के लिए किया जाता है: आप केवल सामग्री चाहते थे यदि संसाधन बदल गया था, लेकिन यह नहीं है, इसलिए मैं आपको कोई सामग्री नहीं दूंगा।

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

Answer 7

आपको वास्तव में केवल दो चीजों में से एक करना चाहिए

या तो एक 200 (OK)स्थिति कोड लौटें , और शरीर में एक खाली सरणी।

या एक 204 (NO CONTENT)स्थिति कोड और कोई प्रतिक्रिया निकाय लौटाएं ।

मेरे लिए, विकल्प 2 तकनीकी रूप से सही और REST और HTTP सिद्धांतों के अनुरूप है।

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

Answer 8

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

Answer 9

विचार करने वाली पहली बात, जब से आप एक RESTful API बना रहे हैं, एक उपयुक्त प्रतिक्रिया कोड वापस करना है। और संवाद करने के लिए अधिक उपयुक्त प्रतिक्रिया कोड है कि अनुरोध सामान्य रूप से चला गया, लेकिन अनुरोधित संसाधन फिलहाल उपलब्ध नहीं है 404 है।

यदि आप अपने एपीआई को इस तरह से डिज़ाइन करते हैं कि यह हमेशा एक समझदार प्रतिक्रिया कोड देता है, तो संसाधन नहीं मिलने पर आपको एक निकाय को वापस करने की आवश्यकता भी नहीं हो सकती है। उस ने कहा, एक शरीर, विशेष रूप से एक मानव पठनीय वापसी, चोट नहीं कर सकता।

यहां कोई "सर्वश्रेष्ठ अभ्यास" नहीं है, आपके दोनों उदाहरण मनमानी हैं, बस एक को चुनें और सुसंगत रहें । डेवलपर्स आश्चर्य नफरत है, अगर /v1/get/moviesरिटर्न {}जब कोई फ़िल्में दी गई हैं तो हम उम्मीद थी /v1/get/actorsभी वापस जाने के लिए {}जब वहाँ कोई अभिनेता हैं।

Comments

एक 404 लौटना वास्तव में सही काम है, लेकिन दुख की बात यह है कि वास्तव में कोई भी ऐसा नहीं करता है - खुद को शामिल करना।

— रिबेलडैडी

यदि आपके पास जटिल प्रतिक्रियाएं हैं, और उनमें से केवल हिस्से खाली हैं, तो 404 लौटाने से उपयोगकर्ता भ्रमित हो जाएगा।

— देवनाउल

मैं 404 संदेश से असहमत हूं। एक 404 मैं "संसाधन मौजूद नहीं है" के रूप में व्याख्या करेगा और मुझे अपने URL या जो कुछ भी गलत है, उसकी चिंता होगी। अगर मैं फिल्मों की सूची मांगता हूं और 404 मिलता है तो मुझे लगता है कि फिल्म संसाधन नहीं है। "204 नो कंटेंट" अधिक उपयुक्त हो सकता है।

— थोरस्टेन मुलर

ठीक है, "नो बॉडी" वाली चीज इसे मार देगी। लेकिन: "4xx क्लास ऑफ़ स्टेटस कोड उन मामलों के लिए अभिप्रेत है जिसमें ग्राहक को मिटा दिया गया है।" लेकिन क्लाइंट की तरफ से कोई त्रुटि नहीं थी। तो एक 404 गलत जानकारी देता है। या तो एक शरीर के बिना 204 भेजें या कहें कि यह ठीक है और एक खाली सूची भेजें।

— थोरस्टेन मुलर

आप किताबों की एक सूची के लिए पूछ रहे हैं, 404 लौटाने का मतलब होगा कि सूची मौजूद नहीं है, यह नहीं कि यह खाली है। खाली सूची के साथ 200 वापस करना मेरे लिए एकमात्र उचित विकल्प लगता है।

— अवकर

Answer 10

मुझे नहीं लगता कि कठोर उत्तर वह है जो चिह्नित है।

सही रीस्ट परिदृश्य में nirth द्वारा प्रदान किया गया उत्तर सबसे अच्छा होना चाहिए। शरीर की प्रतिक्रिया खाली होनी चाहिए और http स्थिति कोड: 204; संसाधन मौजूद है, लेकिन उस समय इसमें "कोई सामग्री नहीं" है: खाली है।

REST HTTP_Status_Codes

Answer 11

मैं 200 + खाली सरणी की सलाह देता हूं, क्योंकि यह एपीआई के सभी क्लाइंट द्वारा हैंडलिंग को सरल करता है। 200 + सरणी का अर्थ है "मैंने वहां मौजूद सभी डेटा वापस कर दिया"। डेटा पहुंचाने वाले कोड और इसे संसाधित करने वाले कोड, दोनों की संख्या अप्रासंगिक होगी।

हर दूसरे स्टेटस कोड को सर्वर द्वारा ठीक से डॉक्यूमेंट और सही तरीके से डिलीवर किया जाना चाहिए और क्लाइंट द्वारा ठीक से प्रोसेस किया जाना चाहिए, और हम सभी जानते हैं कि ऐसा होने की कितनी संभावना है।

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

Answer 12

मैं "यह निर्भर करता है"।

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

मुझे यकीन है कि आप मेरे उदाहरण की बारीकियों के साथ बहस कर सकते हैं, लेकिन आपको यह विचार है ...

Answer 13

• सबसे पहले, getआपके URL में RESTful नहीं है, GET HTTP विधि द्वारा निहित है।
• यदि आप एक संग्रह की रिक्वेस्ट कर रहे हैं जैसे कि खाली सरणी के साथ GET api/moviesलौटें ।200 OK[]
• यदि आप एक विशिष्ट फिल्म का अनुरोध कर रहे हैं जैसे GET api/movies/1(जहां 1आईडी है) और यह मौजूद नहीं है, तो वापस लौटें 404 Not Found।

क्यों? आप संसाधनों का अनुरोध कर रहे हैं । जब आप संग्रह का अनुरोध कर रहे हैं, तो संसाधन स्वयं (संग्रह) मौजूद है। वहाँ, एक 404गलत है। लेकिन यदि आप एक विशिष्ट फिल्म का अनुरोध करते हैं और यह मौजूद नहीं है, तो अनुरोध किया गया संसाधन मौजूद नहीं है, और आपको वापस लौटना होगा 404।

Answer 14

यदि आप JSON लौटा रहे हैं, तो हमेशा गिनती और त्रुटि संदेश वापस करना बेहतर होता है और शायद एक बूलियन जो इंगित करता है कि यदि त्रुटि है या नहीं, तो यह मेरी मानक तीन मेटा मान पंक्तियों की प्रत्येक सूची के साथ वापस आ गया है।