58

मैं एक परियोजना पर काम कर रहा हूं और लगभग एक घंटे से अधिक समय तक लोगों के साथ बहस करने के बाद। मैंने यह जानने का फैसला किया कि स्टैक-एक्सचेंज पर लोग क्या कह सकते हैं।

हम एक सिस्टम के लिए एक एपीआई लिख रहे हैं, एक क्वेरी है जिसे संगठन के एक पेड़ या गोल के एक पेड़ को वापस करना चाहिए।

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

मैं आग की लपटों और रोष को रोकने की कोशिश करूँगा।

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

और जानकारी,

मैं उन उरोजों को जोड़ना भूल गया जो भ्रूण हैं।

संगठन

/OrgTree/Get

लक्ष्य

/GoalTree/GetByDate?versionDate=...
/GoalTree/GetById?versionId=...

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

अतिरिक्त

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

मुझे भी यह जुड़ा हुआ मिला (एक समान लेकिन मैं इसे नहीं पा सकता)

http://viswaug.files.wordpress.com/2008/11/http-headers-status1.png

api http http-response

— Loc Faure-Lacroix
स्रोत

स्पष्ट करें: कैसे आवेदन अलग गिर सकता है कोई पेड़ है जब वहाँ, एक पेड़ है अगर वहाँ हमेशा पूर्व शर्त से ? (मैं आपसे सहमत हूं कि यह 404 जैसा दिखता है)

— एंड्रेस एफ।

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

— लोउक फ्योर-लैक्रोस

4

यदि आप उस संसाधन के लिए URI देते हैं जो आप एक्सेस करने का प्रयास कर रहे हैं तो यह स्पष्ट होगा। यदि यह / लक्ष्य / आप 200 और खाली सेट लौटाते हैं। यदि आप / लक्ष्य / {goal_id} एक्सेस करने का प्रयास कर रहे हैं, तो आप 404 लौटाते हैं। यदि आप 404 / लक्ष्यों / के लिए अनुरोध के लिए लौटे हैं, तो इसका मतलब है कि URI मौजूद नहीं है और इसका अब उपयोग नहीं किया जाना चाहिए।

— imel96

1

अभी भी दोनों ही मामलों में सवाल है। क्या /GoalTree/GetById?versionId=CompletelyInvalidIDलौटना चाहिए ? सफलता नहीं, जैसा कि नामित संसाधन /GoalTree/GetById?versionId=CompletelyInvalidIDका शाब्दिक अर्थ नहीं मिला।

2

महान, अब चर्चा आपके काम से इंटर्नेट पर स्थानांतरित हो गई है! यह अब अजेय है!

— कार्लोस कैंपडरो जूल

79

जब संदेह हो, तो प्रलेखन से परामर्श करें । HTTP स्थिति कोड के लिए W3C परिभाषाओं की समीक्षा करना, हमें यह देता है:

200 ठीक - अनुरोध सफल हो गया है। प्रतिक्रिया के साथ लौटी जानकारी अनुरोध में प्रयुक्त विधि पर निर्भर है।

404 नहीं मिला - सर्वर को अनुरोध-यूआरआई से मेल खाते हुए कुछ भी नहीं मिला है।

आपके एपीआई के संदर्भ में, यह बहुत कुछ इस बात पर निर्भर करता है कि प्रश्न कैसे बनाए जाते हैं और वस्तुओं को कैसे प्राप्त किया जाता है। लेकिन, मेरी व्याख्या हमेशा यही रही है:

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

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

मुझे लगता है कि विकिपीडिया इसे सबसे अच्छा रखता है:

200 ठीक - ... वास्तविक प्रतिक्रिया उपयोग की गई अनुरोध विधि पर निर्भर करेगी। GET अनुरोध में, प्रतिक्रिया में अनुरोधित संसाधन के अनुरूप एक इकाई होगी।

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

मुझे बहुत स्पष्ट लगता है।

उदाहरण अनुरोधों के संबंध में

/GoalTree/GetByDate?versionDate=...
/GoalTree/GetById?versionId=...

प्रारूप के लिए, आपने कहा था, आप हमेशा उस तिथि को निकटतम संशोधन लौटाते हैं। यह कभी भी एक वस्तु नहीं लौटाएगा, इसलिए इसे हमेशा लौटाना चाहिए 200 OK। यहां तक कि अगर यह एक तिथि सीमा लेने में सक्षम था, और तर्क उस समय सीमा के भीतर सभी वस्तुओं को वापस करने के लिए 200 ठीक थे - 0 परिणाम ठीक है, जैसा कि अनुरोध था - चीजों का सेट जो उस मानदंड को पूरा करता है।

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

स्टेटस कोड चुनने के बारे में

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

आपने 5xx कोड का उपयोग करते हुए एक टिप्पणी में उल्लेख किया है, लेकिन आपका सिस्टम काम कर रहा है। यह एक प्रश्न पूछा गया था जो काम नहीं करता है और इसे यूए से संवाद करने की आवश्यकता है। कोई फर्क नहीं पड़ता कि आप इसे कैसे काटते हैं, यह 4xx क्षेत्र है।

हमारे सौर मंडल के एक विदेशी प्रश्न पर विचार करें

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

कंप्यूटर: 1 परिणाम मिला। पृथ्वी

एलियन: कंप्यूटर, कृपया मुझे पृथ्वी के बारे में बताएं ।

कंप्यूटर: पृथ्वी - ज्यादातर हानिरहित।

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

कंप्यूटर: 0 परिणाम मिले।

एलियन: कंप्यूटर, कृपया पृथ्वी को नष्ट कर दें।

कंप्यूटर: 200 ठीक है।

एलियन: कंप्यूटर, कृपया मुझे पृथ्वी के बारे में बताएं ।

कंप्यूटर: 404 - नहीं मिला

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

कंप्यूटर: 0 परिणाम मिले।

एलियन: शक्तिशाली इरकेन साम्राज्य के लिए विजय!

— निक त्सै
स्रोत

4

+1 यह कोई क्वेरी नहीं है जो कोई परिणाम नहीं देता है। यह एक ज्ञात वेबपेज के लिए ब्राउज़र को पूछने और उसे नहीं ढूंढने जैसा है। वास्तव में 404 क्या है।

— एंड्रेस एफ।

2

@ imel96 आप भूल जाते हैं कि क्वेरी स्ट्रिंग URL का हिस्सा है।

— लोकेक फ्योर-लैक्रोस

1

@LegoStormtroopr आपका मनोरंजक "एलियन" उदाहरण काम करता है क्योंकि जब पृथ्वी मौजूद नहीं है तो ब्रह्मांड अमान्य नहीं है। लेकिन ओपी के स्पष्टीकरण के अनुसार, उनकी प्रणाली में पेड़ शामिल होना चाहिए । पेड़ के बिना, सिस्टम काम नहीं करता है।

— एंड्रेस एफ।

1

@LegoStormtroopr एक डेटाबेस तालिका की कल्पना करता है। आप तालिका को क्वेरी करते हैं, कभी-कभी आपको परिणाम मिलता है, कभी-कभी आप नहीं करते हैं। टेबल आपका संसाधन है, यह हमेशा परवाह किए बिना है कि यह पंक्तियों को वापस कर रहा है या नहीं। तालिका पहचानने योग्य है, इसे नाम मिला है (जैसे http संसाधनों में URI हैं)। पंक्तियाँ नहीं हैं, वे केवल कुछ मापदंडों से मेल खाते हैं। डेटाबेस में भी, यदि आप एक अपडेट करते हैं जो कुछ भी नहीं से मेल खाता है, तो आपको "ओके 0 रो प्रभावित" मिलेगा।

— imel96

2

@LegoStormtroopr आपके पास पहले से ही उत्तर है। यदि वे / GoalTree / GetById; versionId = x को रीमैप करना चाहते हैं, तो उसे 301 स्थान / हैडलट्री / आईडी / x पर सेट हैडर के साथ वापस आ जाना चाहिए।

— imel96

11

इस तथ्य को अनदेखा करना कि / GoalTree / Get * एक क्रिया की तरह दिखता है, संसाधन नहीं, आपको हमेशा 200 वापस करना चाहिए क्योंकि URI / GoalTree / Get * उन संसाधनों का प्रतिनिधित्व करता है जो हमेशा पहुंच के लिए उपलब्ध हैं और यह क्लाइंट त्रुटि नहीं है यदि परिणामस्वरूप कोई पेड़ नहीं है एक दरख्वास्त। जब कोई इकाई वापस न हो, तो खाली सेट के साथ 200 लौटें।

यदि संसाधन नहीं है, तो आप 404 का उपयोग करते हैं, जब कोई इकाई नहीं है।

इसे दूसरे तरीके से रखें, यदि आप अपनी वस्तुओं के लिए 404 वापस करना चाहते हैं, तो उन्हें अपने स्वयं के यूआरआई दें।

— imel96
स्रोत

1

हम्म। यह समझ में आता है। 404 एक उपयोगकर्ता त्रुटि है, लेकिन जैसा कि ओपी बताते हैं, यह वास्तव में एक सिस्टम त्रुटि है; उपयोगकर्ता का अनुरोध पूरी तरह से मान्य है! मैं 200 से असहमत हूं, हालांकि सही प्रतिक्रिया है, क्योंकि "कोई पेड़ नहीं" एक त्रुटि है ।

— एंड्रेस एफ।

@ imel96 मैं मान्य संस्थाएँ हमेशा खाली / स्थिति कोड 4xx / 5xx के बजाय लौटाता हूँ। अगर यह सिर्फ मुझे था, तो मैं एक वैध इकाई को वापस कर दूंगा जैसे कि उदाहरण के लिए एक विकि करता है। कम सिरदर्द को त्रुटियों को संभालने की कोई आवश्यकता नहीं है। जैसा कि है, मैं कहूंगा कि यह 500 की तरह बहुत सुंदर है। यह प्रणाली अपरिभाषित स्थिति में है, ऐसा नहीं होना चाहिए। और ठीक लौटने का कोई मतलब नहीं है। 404 rfc के बारे में भी कोई मतलब नहीं है। तो जब कुछ भी समझ में नहीं आता है ... केवल 500 समझ में आता है!

— Locc Faure-Lacroix

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

— imel96

+1 यदि आपके पास एक REST API था (प्रत्येक इकाई का अपना रास्ता था) तो आप 404 लौटा सकते हैं, लेकिन आपके रास्ते क्रियात्मक हैं और हमेशा मिलेंगे।

— मोनिका

@OrangeDog: /GoalTree/GetById?versionId=12345 है एक पूरी तरह से अच्छा यूआरआई (अच्छी तरह से, एक रिश्तेदार से एक है, कम से कम) जो किसी विशिष्ट संसाधन, अर्थात् डेटा संस्करण आईडी के साथ संगत की पहचान करता है 12345प्रणाली में। यदि ऐसी आईडी वाला कोई डेटा मौजूद नहीं है, तो 404 HTTP प्रतिक्रिया पूरी तरह से उचित है। बेशक, प्रतिक्रिया निकाय को, किसी भी मामले में, उचित रूप से स्वरूपित प्रतिक्रिया (जैसे JSON, यदि ऐसा है कि विशिष्ट ग्राहक इस तरह के संसाधनों का अनुरोध करते हैं) में विशिष्ट प्रकृति और त्रुटि के कारण का संकेत होता है।

— इल्मरी करोनन

7

यह एक दिलचस्प सवाल है, क्योंकि यह सिस्टम के विनिर्देश के बारे में है।

imel96 की प्रतिक्रिया ने मुझे आश्वस्त किया है कि 404 एक उचित प्रतिक्रिया नहीं होगी, क्योंकि कोड के 4xx परिवार मुख्य रूप से उपयोगकर्ता / ग्राहक त्रुटियों के लिए है , और यह एक नहीं है। URL अच्छी तरह से बना है और पेड़ अवश्य होना चाहिए; यदि यह नहीं है, तो सिस्टम असंगत स्थिति में है!

इसलिए यह एक सर्वर त्रुटि है, यानी 5xx परिवार में कुछ। संभवतः एक सामान्य 500 आंतरिक सर्वर त्रुटि या 503 सेवा अनुपलब्ध (सेवा मुझे "उस पेड़ को लाने चाहिए जो वहां होना चाहिए")।

— एंड्रेस एफ।
स्रोत

2

सच नहीं है, उपयोगकर्ता गलती में है क्योंकि उन्होंने कुछ ऐसा करने के लिए कहा है जो मौजूद नहीं है ।

@LegoStormtroopr ऐसी चीज़ के लिए पूछना जो अस्तित्व में नहीं है, हमेशा एक त्रुटि नहीं होती है। यदि आप एक नेटवर्क संसाधन के लिए पूछते हैं, और नेटवर्क नीचे है, तो यह एक नेटवर्क त्रुटि है।

— एंड्रेस एफ।

1

@LegoStormtroopr इसके अलावा, पेड़ मौजूद होना चाहिए ; ओपी के स्पष्टीकरण के अनुसार, सिस्टम इसके बिना कार्य नहीं कर सकता है। इसलिए, इस संसाधन के लिए पूछना मान्य है; यदि यह नहीं है, तो यह एक सिस्टम (या सर्वर) त्रुटि होनी चाहिए ।

— एंड्रेस एफ।

2

@Sybiam यदि आप 5xx कोड के रूट पर जा रहे हैं, तो 503 "503 सर्विस अनुपलब्ध है - सर्वर वर्तमान में सर्वर के एक अस्थायी ओवरलोडिंग या रखरखाव के कारण अनुरोध को संभालने में असमर्थ है।" आपका सर्वर अतिभारित नहीं है, इसका अनुरोध नहीं मिल रहा है। इसके अतिरिक्त, 5xx कोड तब होते हैं जब "सर्वर को पता चल जाता है कि यह मिटा दिया गया है या अनुरोध करने में असमर्थ है"

1

@AndresF। सच कहूं तो, एक 500 कोड शायद ठीक है। यह देखते हुए कि समय के साथ सवाल कैसे बदल गया है, यह काम करेगा। ज्यादातर, मैं 200 पर लौटने के खिलाफ रैली कर रहा हूं अगर सब कुछ ठीक नहीं है।

6

मैं कहूंगा कि या तो 200 या 404 प्रतिक्रिया कोड मान्य हो सकता है , यह इस बात पर निर्भर करता है कि आप स्थिति को कैसे देखते हैं।

बात यह है कि HTTP प्रतिक्रिया कोड एक सर्वर के संदर्भ में परिभाषित किए गए हैं , जो उनके URL के आधार पर विभिन्न संसाधनों को वितरित कर सकते हैं । इस संदर्भ में, के अर्थ 200 OKऔर 404 Not Foundपूरी तरह से स्पष्ट कर रहे हैं: पूर्व कहते हैं, "यहां संसाधन आप के लिए कहा है", जबकि बाद कहते हैं, "माफ करना, मुझे लगता है कि जैसे किसी भी संसाधन नहीं है"।

हालाँकि, आपकी स्थिति में, आपके पास HTTP सर्वर और वास्तविक संसाधनों (पेड़ों) के बीच एक अतिरिक्त अनुप्रयोग परत है जो अनुरोध किया जा रहा है। एप्लिकेशन एक तरह का मध्यवर्ती स्थान घेरता है जो HTTP कल्पना में अच्छी तरह से संबोधित नहीं है।

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

विशेष रूप से, आपके उदाहरण के मामले में, वेबसर्वर आवेदन का ठीक-ठीक पता लगा सकता है, लेकिन आवेदन तब अनुरोध किए गए सबसोर्स (पेड़) का पता लगाने में विफल रहता है। अब, यदि आप अनुप्रयोग को सर्वर का सिर्फ एक विस्तार मानते हैं, और सबमिट (पेड़) को वास्तविक संसाधन मानते हैं, तो एक 404 प्रतिक्रिया उपयुक्त है: सर्वर ने आवेदन के लिए वास्तविक संसाधन खोजने का काम सौंप दिया है , जो ऐसा करने में विफल रहा है।

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

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

हालाँकि, एक कस्टम उच्च-स्तरीय API प्रोटोकॉल का उपयोग करके अन्य कंप्यूटर प्रोग्राम के साथ संचार करने के लिए डिज़ाइन किए गए एप्लिकेशन के विशिष्ट मामले में, HTTP का उपयोग केवल निम्न-स्तरीय परिवहन परत के रूप में किया जाता है , बाद वाले दृश्य के पक्ष में किए जाने के लिए एक तर्क है : इस तरह के एक अनुप्रयोग के साथ हस्तक्षेप करने वाले ग्राहक, वे सभी वास्तव में परवाह करते हैं, HTTP स्तर पर , यह है कि क्या वे सफलतापूर्वक आवेदन से संपर्क करने में कामयाब हैं या नहीं। बाकी सब कुछ, ऐसे मामलों में, उच्च स्तर के प्रोटोकॉल का उपयोग करके अक्सर अधिक स्वाभाविक रूप से संचार किया जाता है।

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

HTTP स्तर पर, एक खाली संसाधन को केवल 200 प्रतिक्रिया कोड और एक खाली प्रतिक्रिया निकाय द्वारा इंगित किया जाएगा, जबकि एक गैर-संसाधन संसाधन को 404 प्रतिक्रिया और संसाधन निकाय द्वारा संसाधन की अनुपस्थिति के बारे में बताते हुए इंगित किया जाएगा। एक उच्च-स्तरीय एपीआई प्रोटोकॉल में, आमतौर पर एक त्रुटि प्रतिक्रिया द्वारा एक उपयुक्त संसाधन-विशिष्ट त्रुटि कोड / संदेश वाले किसी भी प्रकार के संसाधन का संकेत होता है, जबकि एक खाली प्रतिक्रिया बस बिना डेटा आइटम के एक सामान्य प्रतिक्रिया संरचना होगी।

(ध्यान दें कि संसाधन का शाब्दिक अर्थ है कि मैं ऊपर दिए अर्थ में "खाली" होने के लिए शून्य बाइट्स लंबे समय तक नहीं होना चाहिए। उदाहरण के लिए, बिना मिलान वाली वस्तुओं के साथ एक खोज परिणाम व्यापक अर्थों में रिक्त के रूप में गिना जाएगा, जैसा कि SQL क्वेरी परिणाम के साथ होगा। कोई पंक्तियाँ या XML दस्तावेज़ जिसमें कोई वास्तविक डेटा न हो।)

इसके अलावा, निश्चित रूप से, यदि एप्लिकेशन वास्तव में यह मानता है कि अनुरोधित सबरसोर्स होना चाहिए, लेकिन वह नहीं मिल सकता है, तो एक तीसरा संभावित प्रतिक्रिया कोड मौजूद है 500 Internal Server Error:। इस तरह की प्रतिक्रिया से समझ में आता है कि क्या संसाधन का अस्तित्व अनुप्रयोग के लिए एक अनुमानित पूर्व शर्त है, जैसे कि इसकी अनुपस्थिति आवश्यक रूप से एक आंतरिक खराबी का संकेत देती है।

अंत में, आपको हमेशा पोस्टेल के नियम को ध्यान में रखना चाहिए :

" जो आप भेजते हैं उसमें रूढ़िवादी रहें और जो आप प्राप्त करते हैं उसमें उदारता। "

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

— इल्मरी करोनें
स्रोत

दुविधा अच्छी तरह से समझाया।

— मार्सेल

कोई दुविधा नहीं है। यह उत्तर इस बात पर आधारित नहीं है कि संबंधित आरएफसी में संसाधन को किस रूप में परिभाषित किया गया है। मेरी टिप्पणी @LegoStormtroopr उत्तर के तहत देखें।

— imel96

@ imel96: मुझे लगता है कि आप RFC 1630 की गलत व्याख्या कर रहे हैं: आपके द्वारा पहले टिप्पणी में लिखा गया पैराग्राफ, पूर्ण में: "प्रश्न चिह्न ("? ", ASCII 3F हेक्स) का उपयोग किसी क्वेरी के URI के बीच सीमा को परिसीमित करने के लिए किया जाता है?" ऑब्जेक्ट, और शब्दों का एक सेट उस ऑब्जेक्ट पर एक क्वेरी को व्यक्त करने के लिए उपयोग किया जाता है। जब इस फॉर्म का उपयोग किया जाता है, तो संयुक्त URI उस ऑब्जेक्ट के लिए खड़ा होता है, जिसके परिणामस्वरूप क्वेरी को मूल ऑब्जेक्ट पर लागू किया जाता है। " (जोर मेरा)। इस प्रकार, यह स्पष्ट है कि क्वेरी स्ट्रिंग वास्तव में URI का हिस्सा है (भले ही क्वेरी स्ट्रिंग से पहले का हिस्सा आवश्यक हो, अपने आप में एक मान्य URI भी हो ...)

— इल्मरी करोनन

... और यह संयुक्त URI एक विशिष्ट संसाधन की पहचान करता है जिसे ग्राहक उस URI को सर्वर पर भेजकर अनुरोध कर सकता है। किसी भी स्थिति में, RFC 2616 (HTTP) केवल एक संसाधन को "एक नेटवर्क डेटा ऑब्जेक्ट या सेवा के रूप में परिभाषित करता है जिसे URI द्वारा पहचाना जा सकता है, जैसा कि खंड 3.2 में परिभाषित किया गया है।" और आगे कहते हैं कि "जहाँ तक HTTP का संबंध है, यूनिफ़ॉर्म रिसोर्स आइडेंटिफ़ायर केवल स्वरूपित स्ट्रिंग्स होते हैं जो पहचानते हैं - नाम, स्थान या किसी अन्य विशेषता के माध्यम से - एक संसाधन।"

— इल्मरी करोनन

@ इल्मारियारोन आप सही कह रहे हैं। मैंने HTTP को REST के साथ भ्रमित किया है। फिर भी यह सही नहीं लगता, क्योंकि मुझे यकीन नहीं है कि आप URI जैसे किसी संसाधन के साथ क्या कर सकते हैं / GoalTree /: versionDate = 2000BC

— imel96

3

कैसे एक 204 सामग्री के बारे में नहीं? यह सुझाव देगा कि आपके अनुरोध को सफलतापूर्वक संसाधित किया गया था लेकिन कुछ भी नहीं लौटा रहा है। यह अभी भी एक "सफलता" है, लेकिन आपको यह देखने की अनुमति देता है कि क्या आपके पास अकेले स्थिति कोड के आधार पर परिणाम हैं।

— modernserf
स्रोत

6

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

— imel96

3

यदि URL एक ऐसे संसाधन का प्रतिनिधित्व करता है, जो कभी अस्तित्व में नहीं आया तो 404 नहीं मिला

यदि URL एक संसाधन का प्रतिनिधित्व करता है जो एक खाली सूची है तो एक खाली सूची और 200 OK पर वापस लौटें।

उदाहरण:

{
  total: 0,
  items: []
}

यदि URL एक ऐसे संसाधन का प्रतिनिधित्व करता है जो 410 गॉन को वापस करने के लिए मौजूद था।

लेगो स्टॉर्मट्रॉपर के संवाद के बारे में:

Alien: Computer, please tell me all planets that humans inhabit. GET /planets?inhabitedBy=humans

Computer: 200 OK. { total: 1, items:[{name:'Earth'}] }

Alien: Computer, please tell me about Earth. GET /planets/earth

Computer: 200 OK. {name:'Earth', status: 'Mostly Harmless'}

Alien: Computer, please tell me about all planets humans inhabit, outside the asteroid belt. GET /planets?inhabitedBy=humans&distanceFromSun=lots

Computer: 200 OK. {total:0, items:[] }

Alien: Computer, please destroy Earth. DELETE /planets/earth

Computer: 204 No Content. (or 202 Accepted if it takes some time to destroy Earth)

Alien: Computer, please tell me about Earth. GET /planets/earth

Computer: 410 Gone

Alien: Computer, please tell me all planets that humans inhabit. GET /planets?inhabitedBy=humans

Computer: 200 OK 0 {total: 0, items:[] }

Alien: Victory for the mighty Irken Empire!

— नील मैकगिगन
स्रोत

1

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

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

मैं एंड्रेस एफ के दृष्टिकोण से भी सहमत हूं कि 500 उचित है क्योंकि पेड़ मौजूद होना चाहिए । हालांकि व्यवहार में, मुझे सर्वर त्रुटियों को दो श्रेणियों में विभाजित करना पसंद है। कुछ अनपेक्षित गलत हो गया और कुछ ऐसा जो मैं व्यावहारिक रूप से गलत होने की जांच कर सकता हूं। यह निम्न स्थिति कोड में परिणाम करता है,

200 - सब कुछ अच्छा है
404 - गलत यूआरएल
409 - कुछ गलत हो गया
500 - सर्वर पर एक अप्रत्याशित त्रुटि हुई

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

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

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

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

— Despertar
स्रोत

0

इस पर एक स्पर्शनीय छुरा लेना: यदि कोई व्यक्ति अंततः एपीआई (एक जीयूआई के माध्यम से) का उपयोग कर रहा है, तो मैं सुझाव दूंगा कि जो भी करना है वह अंतिम उपयोगकर्ता के लिए जीवन को आसान बनाता है। जब यह मौजूद होना चाहिए तो पेड़ का गैर अस्तित्व "डोमेन मॉडल असंगति" त्रुटि है। सिस्टम त्रुटि तब होती है जब आप मेमोरी से बाहर भागते हैं या कुछ अन्य प्रणालीगत विफलता थी। इसलिए 5xx लौटना अनुचित है। जैसा कि ऊपर कई लोगों ने उल्लेख किया है, 4xx उपयुक्त हो सकता है यदि पेड़ का अपना यूआरआई होता, जो यहां नहीं है। लेकिन यहाँ क्या 404 क्लाइंट को बताता है: आप बार-बार कोशिश कर सकते हैं जब तक आपको कुछ वापस नहीं मिलता। यदि आप 200 लौटे हैं, तो आप उपयोगकर्ता या उपयोगकर्ता एजेंट को पर्याप्त डायग्नोस्टिक्स वापस लौटा सकते हैं ताकि उपयोगकर्ता एजेंट एक मेएज प्रदर्शित कर सके ताकि उपयोगकर्ता रिट्रीट करना बंद कर दे और सिर्फ संपर्क का समर्थन करे। दूसरी ओर यदि यह एपीआई केवल सिस्टम के लिए है,

— user90766
स्रोत

सभी 404 वास्तव में कहते हैं, "यह बात यहाँ नहीं है, और मुझे नहीं पता कि यह कहाँ है"। 3xx और 5xx पुन: प्रयास के लिए ठीक हैं। लेकिन 4xx कहते हैं, "आपके लिए मेरे लिए वर्तमान क्वेरी अपर्याप्त थी।

मुझे URL NOT FOUND और संसाधन NOT FOUND के बीच अंतर करने की संभावना पसंद है ... इसलिए सेवा समापन बिंदु 200 है और चल रहा है, हालाँकि अनुरोधित संसाधन 404 नहीं है (रिस्पांस बॉडी)।

— नींबू पानी

जब एक एपीआई में HTTP स्थिति कोड 404 का उपयोग करना है

और जानकारी,

अतिरिक्त

मुझे भी यह जुड़ा हुआ मिला (एक समान लेकिन मैं इसे नहीं पा सकता)

उदाहरण अनुरोधों के संबंध में

स्टेटस कोड चुनने के बारे में

हमारे सौर मंडल के एक विदेशी प्रश्न पर विचार करें