मैं "अभी तैयार नहीं, बाद में फिर कोशिश करूँ" के लिए REST API में एक HTTP स्थिति कोड कैसे चुनूँ? [बन्द है]


152

मैं एक RESTful API विकसित कर रहा हूं जिसमें http://server/thingyapi/thingyblob/1234डाउनलोड करने के लिए # 1234 के साथ जुड़ी फाइल (उर्फ "बूँद") लौटाता है। लेकिन यह हो सकता है कि अनुरोध उस समय किया जाता है जब फ़ाइल सर्वर में मौजूद नहीं होती है लेकिन सबसे निश्चित रूप से बाद के समय में उपलब्ध होगी । सर्वर में एक बैच प्रक्रिया है जो सभी चीज़ों के लिए सभी ब्लब्स उत्पन्न करती है। थिंगी 1234 पहले से मौजूद है और इसका डेटा, बूँद के अलावा, पहले से ही उपलब्ध है। सर्वर अभी तक 1234 की बूँद पैदा करने के लिए नहीं मिला है।

मैं 404 नहीं लौटना चाहता; यह उन चीज़ों के लिए है जिनका अस्तित्व नहीं है। यह एक ऐसी चीज़ है जो मौजूद है, लेकिन इसकी बूँद अभी तक उत्पन्न नहीं हुई है। किंडा एक YouTube वीडियो पसंद करता है जो "प्रसंस्करण" है। मुझे नहीं लगता कि पुनर्निर्देशन कोड या तो उचित होगा; कोशिश करने के लिए कोई "अन्य" URL नहीं है।

ऐसे मामले में लौटने के लिए सही HTTP स्थिति कोड क्या है?



7
सबसे पहले, अगर बात 1234 में अभी तक कोई GET- सक्षम प्रतिनिधित्व नहीं करता है, तो यह किस अर्थ में एक संसाधन (ग्राहक के दृष्टिकोण से) के रूप में मौजूद है? तथ्य यह है कि, सर्वर पर आंतरिक 1234 बनाने के लिए एक कतारबद्ध कार्य है, संसाधन 1234 मौजूद होने का अर्थ नहीं लगता है। दूसरा, क्लाइंट को URI कहां मिला ... / thingyblob / 1234? सर्वर शायद ग्राहक को उस URI को प्रदान नहीं करना चाहिए था जब तक कि संसाधन वास्तव में GET-सक्षम नहीं था।
एंडी डेनी

1
एक चीज़ में अन्य गुण होते हैं जो बूँद के अलावा अन्य प्राप्त करने के लायक हैं। यह केवल बूँद है जो उत्पन्न करने में समय लेती है। उदाहरण के लिए, क्लाइंट को वो
JCCyC

10
HTTP मानक मार्गदर्शन प्रदान करता है कि किन स्थितियों के लिए कौन से कोड का उपयोग करना है। इसलिए यह सवाल वास्तव में मुख्य रूप से राय आधारित नहीं है
राएडवल्ड

2
204"नो कंटेंट" के बारे में कैसे ? इंगित करता है कि सर्वर ने अनुरोध को सफलतापूर्वक संसाधित किया है और इस समय कोई भी सामग्री नहीं लौटा रहा है।
तिमो

जवाबों:


77

मैं सुझाव देता हूं 202 - Accepted। से प्रलेखन :

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


62
-1: यह उस अनुरोध के लिए समझ में आता है जो उस प्रक्रिया को शुरू करता है जो अंततः "चीज़ # 1234" बनाता है, लेकिन बाद में "बात # 1234" के लिए जारी किए गए GET अनुरोध के लिए नहीं। विशेष रूप से, एक 202 सुझाव देता है कि GET अनुरोध के परिणामस्वरूप, सेवा बाद में एक समय में "चीज़ # 1234" के लिए डेटा भेज देगी। यह केवल सही नहीं है।
सैम हरवेल

7
यह भी कहता है: "इस प्रतिक्रिया के साथ लौटी इकाई SHOULD में अनुरोध की वर्तमान स्थिति का संकेत और या तो स्थिति की निगरानी के लिए एक संकेतक या उपयोगकर्ता के अनुरोध के पूरा होने की उम्मीद के कुछ अनुमान शामिल हो सकते हैं", इसलिए यह होगा। ग्राहक को यह बताने का अच्छा तरीका है कि बूँद अभी तैयार नहीं है, और यह पता लगाने का एक तरीका है कि यह कब तैयार है।
रेमी लेबेउ

3
मैं तर्क दूंगा कि "प्रसंस्करण के लिए स्वीकृत" इंगित करता है कि आप बाद में कार्य किए जाने के अनुरोध को सहेज रहे हैं। यदि इसे केवल अनदेखा किया जा रहा है, तो आपको क्लाइंट को इंगित करने के लिए 4xx या 5xx कोड वापस करना चाहिए जिसे वे फिर से आज़माना चाहें।
ल्यूक

3
102 (प्रसंस्करण) भी एक उचित विकल्प लगता है, भले ही यह वेबदव कल्पना में है।
akostadinov

2
इस उत्तर से अधिक असहमत नहीं हो सकते। सर्वर कुछ भी वापस नहीं कर रहा है, या इस अनुरोध के कारण कोई प्रसंस्करण नहीं कर रहा है (जो कि वैसे भी जीईटी के लिए नहीं होना चाहिए)। जैसे, संसाधन कुछ फैशन में है जो क्लाइंट के लिए उपलब्ध नहीं है। इसे एक त्रुटि के रूप में माना जाना चाहिए ताकि कोई 2XX कोड उपयुक्त न हो। 4XX या 5XX अंतरिक्ष में कुछ। अनुरोध "प्रसंस्करण के लिए स्वीकार नहीं किया गया है" , अनुरोध को खारिज कर दिया जा रहा है
एडम 15

52

"समस्या", जैसे कि यह है, सर्वर की तरफ है: क्लाइंट ने एक अच्छी तरह से गठित अनुरोध किया है, लेकिन सर्वर इसे संतुष्ट नहीं कर सकता है। तो मैं एक "सर्वर त्रुटि", 5xx स्थिति कोड के लिए इच्छुक हूं।

Roth RFC 7231 (वर्तमान HTTP मानक, जोर जोड़ा):

5xx (सर्वर त्रुटि) स्थिति कोड का वर्ग इंगित करता है कि सर्वर को पता है कि यह मिटा दिया गया है या अनुरोधित विधि को करने में असमर्थ है । HEAD अनुरोध का जवाब देते समय, सर्वर SHOULD एक त्रुटि स्थिति की व्याख्या सहित एक प्रतिनिधित्व भेजता है, और यह एक अस्थायी या स्थायी स्थिति है या नहीं।

ध्यान दें

  • "मिटाया या अनुरोध करने में असमर्थ है": "सर्वर त्रुटि" के अपने शीर्षक के बावजूद, वे केवल सर्वर त्रुटियों के लिए नहीं हैं।
  • " अस्थायी या स्थायी": ये कोड आपके जैसे अस्थायी रूप से अनुपलब्ध संसाधनों के लिए उपयुक्त हैं।

उपलब्ध कोड में से, मैं कहूँगा 503, "सेवा अनुपलब्ध" सबसे उपयुक्त था:

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

ध्यान दें:

  • "कुछ देरी के बाद संभावना कम हो सकती है": आपके मामले के लिए सच है।
  • "अस्थाई अधिभार": आपके मामले के लिए पांडित्यिक रूप से सच नहीं है। लेकिन, यह तर्क दिया जा सकता, थे अपने सर्वर बहुत तेजी से, बैच प्रोसेसिंग पहले से ही जब ग्राहक अनुरोध किया किया गया होता, तो यह है "अधिभार" का एक प्रकार: ग्राहक तेजी से सर्वर से संसाधनों के लिए पूछ रहा है कर सकते हैं उन्हें उपलब्ध है।
  • पुनः प्रयास करना आपकी सेवा के लिए उपयुक्त है, इसलिए आपके उत्तर में एक Retry-Afterमूल्य शामिल होना चाहिए । आप बैच प्रक्रिया के अगले निष्पादन के अनुमानित समापन समय, या बैच प्रक्रिया के निष्पादन अंतराल के मूल्य के रूप में प्रदान कर सकते हैं।

अपने स्वयं के 5xx स्थिति कोड को परिभाषित करना (591, उदाहरण के लिए), हालांकि अनुमति दी गई , गलत शब्दार्थ होगा:

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

ग्राहक आपके स्वयं के स्थिति कोड को 500, "आंतरिक सर्वर त्रुटि" के रूप में मानेंगे , जो सही नहीं होगा।


2
मैं यह देखने में विफल रहता हूं कि यह 202 से बेहतर कैसे है: benramsey.com/blog/2008/04/…
JCCyC

4
@JCCyC आपके ब्लॉग को कुछ बनाने के अनुरोध के जवाब में 202 (एक POST या PUT) वापस करने के लिए एक अच्छा मामला बनाता है। सवाल यह लगता है कि जीईटी के लिए क्या करना है।
राेडवल्ड

@JCCyC को नॉट-रेडी-नेस के एक अलग शेड के रूप में देखा जा सकता है: उस एंज़ैक्स के लिए अजाक्स की कल्पना करें, क्या आप 202 को सफलता की स्थिति के रूप में पसंद करते हैं या 503 को एक त्रुटि स्थिति के रूप में पसंद करते हैं? इसलिए आप देख सकते हैं कि आप अपने ऐप के जवाब की प्रतिक्रिया के संदर्भ में कौन सा अर्थ पसंद करते हैं
rloth

भी मैं का व्यावहारिक पहलू की तरह "पुन: प्रयास करें-के बाद" है कि कुछ किया जा रहा है "तैयार नहीं है" के साथ अच्छी तरह से चला जाता है
rloth

1
एनबी: "पुन: प्रयास करें-के बाद" भी जा सकते हैं के साथ 307 - TEMPORARY REDIRECTजो अच्छा करता है, तो आप कहीं और प्रतीक्षा करने के लिए, जबकि अपनी ressource जा रहा है "बनाया तैयार" है बल ग्राहक के पक्ष करना चाहते है
rloth

28

मुझे लगता है कि 423 - इस उद्देश्य के लिए लॉक का उपयोग किया जा सकता है:

423 (लॉक्ड) स्थिति कोड का मतलब है कि किसी विधि का स्रोत या गंतव्य संसाधन लॉक है। इस प्रतिक्रिया SHOULD में एक उपयुक्त पूर्व शर्त या पोस्टकंडिशन कोड होता है, जैसे 'लॉक-टोकन-सबमिट' या 'नो-परस्पर विरोधी लॉक'।


1
बहुत बढ़िया जवाब! मुझे आश्चर्य है कि यह अधिक upvotes क्यों नहीं है।
lex82

10
शायद इसलिए कि यह एक WebDAV HTTP कोड है?
स्टीफन एल

1
अक्का-http से स्टेटसकोड रिट्रीविथ = reg (c (449) ("रीट्री विद", "अनुरोध उचित कार्रवाई करने के बाद वापस लिया जाना चाहिए।")) जहां कार्रवाई प्रतीक्षा और पुन: प्रयास
करेगी

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

22

मैं 404 नहीं लौटना चाहता; यह उन चीज़ों के लिए है जिनका अस्तित्व नहीं है।

URL किसी चीज़ के लिए अनुरोध के अनुरूप नहीं है।

http://server/thingyapi/thingyblob/1234

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

404।


1
मुझे खुशी है कि किसी ने यह कहा! मैं विश्वास नहीं कर सकता कि बहुत सारे लोग हैं जो सोचते हैं कि 503यह एक उचित प्रतिक्रिया है। कुछ अन्य अजीब सुझावों का उल्लेख नहीं करना।
जेसन देसोस्सिएर्स

हालांकि मैं मानता हूं कि 404 यहां सबसे उपयुक्त प्रतिक्रिया है, लेकिन यह ओपी के सवाल का जवाब नहीं देता है कि जब बात उपलब्ध हो तो कैसे इंगित करें :-)। मुझे लगता है कि रिट्री-आफ्टर फील्ड सबसे अच्छा उम्मीदवार लगता है लेकिन यह केवल आधिकारिक तौर पर 503 और 3xx कोड के लिए इस्तेमाल किया जा सकता है। @ जेसन: मुझे लगता है कि कुछ अजीब सुझाव बताते हैं।
रॉन डीजर्स

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

4
लोगों को 404 अर्थ पेज से बहुत ज्यादा मोहब्बत हो गई है और उन्होंने यह नहीं पाया कि वे एपीआई के संदर्भ में तार्किक रूप से अलग नहीं हो सकते।
मफिन मैन

1
यह sooooo 404 है। Thingyblob अभी तक, या कभी भी मौजूद नहीं है। http के लिए इसका irelevant अगर यह कभी उपलब्ध होगा। फिलहाल यह मौजूद नहीं है, और इसके 404. जब यह उपलब्ध होगा, एक और समस्या है, जिसे सर्वर से क्लाइंट कहे जाने वाले चीज़बेलोब: 1234 में एक मेसेज को धक्का देकर हल किया जा सकता है। एक बार फिर से प्रदर्शन करें और आवाज करें ..
100r

21

एक अन्य विकल्प 503 - Service Unavailable:।


5
W3C के अनुसार यह वह नहीं है जो आप क्लाइंट से कहना चाहते हैं (हालांकि इसका मतलब है "किसी तरह से फिर से आना"): "सर्वर वर्तमान में अस्थायी ओवरलोडिंग या सर्वर के रखरखाव के कारण अनुरोध को संभालने में असमर्थ है। इसका निहितार्थ यह है कि यह एक अस्थायी स्थिति है जिसे कुछ देरी के बाद समाप्त कर दिया जाएगा। यदि ज्ञात हो, तो देरी की लंबाई एक रिट्री-आफ्टर हैडर में इंगित की जा सकती है। यदि कोई रिट्री-आफ्टर नहीं दिया जाता है, तो क्लाइंट प्रतिक्रिया को संभाल लेगा क्योंकि यह उसके लिए होगा। 500 प्रतिसाद। "
स्केली

4
सेवा अनुपलब्ध नहीं है, सेवा उपलब्ध है लेकिन प्रसंस्करण पूर्ण नहीं है। तो 503 शायद एक अच्छा विचार नहीं है।
इश्तियाक खान

17

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

मेरी राय में रिट्री-आफ्टर हैडर के साथ 302 (पाया) सबसे अच्छा विकल्प होगा, लेकिन मुझे यकीन नहीं है कि प्रतिक्रिया हेडर का स्थान फ़ील्ड यूआरएल के अनुरोध के बराबर हो सकता है। यह वैसे भी परिपत्र पुनर्निर्देशित है।


3
यहां तक ​​कि अगर इसकी अनुमति है, अगर क्लाइंट ने रिट्री-आफ्टर हेडर के लिए समर्थन लागू नहीं किया है, तो उसी पेज पर एक 3xx रिडायरेक्शन अंततः 503 में समाप्त हो सकता है ... (वैकल्पिक रूप से रिट्री-आफ्टर कोर्स हेडर के साथ)
रॉन Deijkers

1
RFC-6585 (अप्रैल 2012) द्वारा जोड़े गए HTTP- 429 "टू रिक्वेस्ट रिक्वेस्ट" के साथ रिट्री-आफ्टर भी मान्य है। यह उचित हो सकता है यदि संसाधन का अभी तक तैयार न होने का कारण यह है कि ग्राहक सर्वर को बहुत अधिक काम करने के लिए दे रहा है।
सिलस एस। ब्राउन

8

४० ९ संघर्ष

इंगित करता है कि अनुरोध अनुरोध में संघर्ष के कारण संसाधित नहीं किया जा सकता है, जैसे कि कई अपडेट के मामले में संपादित संघर्ष। [स्रोत विकिपीडिया]

यह उचित हो सकता है।

यदि आप डेटा वापस करके अनुरोध को पूरा नहीं कर सकते - तो इसकी सफलता नहीं है। मुझे लगता है कि 202 का सुझाव है कि सर्वर ने अनुरोध को पंक्तिबद्ध किया है और यह बाद में अनुरोध को पूरा करेगा। लेकिन आपके मामले में, अनुरोध अब डेटा के लिए है और विफल हो गया है। यदि आप बाद में पुनः प्रयास करते हैं तो यह एक अलग अनुरोध है।

मुझे लगता है कि आपके पास एक संघर्ष है .. आप डेटा चाहते हैं .. लेकिन इसका संपादन / अद्यतन किया जा रहा है। यह भी मामला होगा यदि थिंग्वाई 1234 पहले से मौजूद था और पहले भी सफलतापूर्वक डाउनलोड किया जा चुका था, लेकिन अब संपादित होने की प्रक्रिया में अनुपलब्ध था जबकि संपादन हो रहा था।


2
निश्चित नहीं है कि यह मतदान क्यों हुआ। मुझे सही उत्तर की तरह लगता है। RFC से: "409 (संघर्ष) स्थिति कोड इंगित करता है कि लक्ष्य संसाधन की वर्तमान स्थिति के साथ संघर्ष के कारण अनुरोध पूरा नहीं किया जा सका। यह कोड उन स्थितियों में उपयोग किया जाता है जहां उपयोगकर्ता संघर्ष को हल करने में सक्षम हो सकता है और अनुरोध को पुनः सबमिट करें। "आपने एक संसाधन के लिए कहा है जो सर्वर वापस नहीं कर सकता क्योंकि सर्वर उस संसाधन को अपडेट करने की प्रक्रिया में है - अर्थात संसाधन की वर्तमान स्थिति के कारण। ग्राहक प्रतीक्षा और पुन: जमा करके इसे हल कर सकता है
एडम

1
@ एडम मुझे लगता है कि "उपयोगकर्ता संघर्ष को हल करने में सक्षम हो सकता है" इसका मतलब यह है कि पुनरुत्थान के बारे में कुछ अलग होगा, केवल प्रतीक्षा के अलावा।
होलिस्टिक डेवलपर

3

501 - लागू नहीं

वास्तव में यह कैसा लगता है। एक विशेषता जो अभी तक लागू नहीं हुई है, लेकिन इसका मतलब है कि भविष्य की उपलब्धता।

यहाँ 5xx त्रुटियों के सारांश का लिंक दिया गया है ।


4
इस प्रश्न के लिए ऐसा लगता है कि यह सुविधा स्वयं मौजूद है, लेकिन अनुरोध की जा रही वस्तु नहीं है।
ल्यूक

@ मेरे उत्तर में लिंक से 501 का वर्णन, '... यह अनुरोध को पूरा करने की क्षमता का अभाव है। आमतौर पर इसका तात्पर्य भविष्य की उपलब्धता से है। ' यह ठीक वही है जो ओपी पूछ रहा था। भले ही उसके सर्वर या डीबी पर डेटा हो या न हो। अंतिम परिणाम यह है कि यह अभी तक एपीआई के माध्यम से सुलभ नहीं है। इसलिए एपीआई अनुरोध को पूरा नहीं कर सकता है, लेकिन इसका मतलब है कि यह भविष्य में http कोड के माध्यम से उपलब्ध होगा।
डेन
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.