क्या एक आरएसटी एपीआई चुपचाप किसी भी क्षेत्र को बदलने के अनुरोध को अनदेखा करनी चाहिए?

Question

एक आराम एपीआई जो एक डेटाबेस के लिए एक इंटरफेस प्रदान पर विचार करें।

चाहिए एक PUT या PATCH अनुरोध जो एक स्तंभ जो डेटाबेस में मौजूद नहीं है के लिए एक नया मान निर्दिष्ट करने के लिए प्रयास करता है पर एक HTTP 400 Bad Request के साथ एक सर्वर प्रतिक्रिया? क्या सर्वर चुपचाप त्रुटि को अनदेखा कर सकता है? क्या सर्वर कुछ और करता है जिसे मैंने यहां उल्लेख नहीं किया है?

Answer 1

तो यह संभव है ग्राहक अतिरिक्त मूल्य के बिना फिर से जमा करने के लिए आप spec से 409 के साथ जवाब देना चाहिए:

10.4.10 409 संघर्ष

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

संघर्ष सबसे PUT अनुरोध के जवाब में होने की संभावना है। उदाहरण के लिए, यदि संस्करण का उपयोग किया जा रहा था और PUT इकाई को संसाधन में परिवर्तन शामिल किया गया था जो पहले (तृतीय-पक्ष) अनुरोध द्वारा किए गए लोगों के साथ संघर्ष करता है, तो सर्वर 40 9 प्रतिक्रिया का उपयोग यह इंगित करने के लिए कर सकता है कि यह ' अनुरोध पूरा नहीं करें। इस मामले में, प्रतिक्रिया इकाई संभावना एक प्रारूप में दो संस्करणों के बीच मतभेदों को प्रतिक्रिया सामग्री प्रकार से परिभाषित किया गया की एक सूची शामिल होगा।

Answer 2

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

400, अच्छा है के रूप में 409 तुम भी 403 निषिद्ध विचार कर सकते हैं है: सर्वर आपके अनुरोध समझा लेकिन यह पूरा करने से इंकार कर रहा है।

400 आम तौर पर खराब गठित अनुरोधों के लिए है।
403 अच्छा है जब अनुरोध पर्याप्त रूप से अच्छी तरह से गठित किया गया था कि आपका सर्वर कोड इसे पार्स करने में सक्षम था और यह समझने के लिए कि अनुरोध क्या था। मुझे लगता है कि यहां आपकी आवश्यकता पूरी तरह से मिलती है।

हालांकि, अपने प्रश्न में एक पंक्ति मुझे चिंता: एक स्तंभ जो डेटाबेस में मौजूद नहीं है

अनुरोध एक डेटाबेस में कॉलम के मूल्यों को संशोधित नहीं किया जाना चाहिए के लिए एक नया मान निर्दिष्ट करने के लिए

प्रयास। उन्हें संसाधन की सामग्री को संशोधित करना चाहिए। दोनो एक जैसे नहीं हैं। सोचने के जाल में गिरना आसान है "ओह, बस इस डोमेन ऑब्जेक्ट को HTTP संसाधन के रूप में बेनकाब करें" लेकिन इससे लाइन के नीचे स्केलेबिलिटी समस्याएं हो सकती हैं। सामान्य रूप से, आपके पास मॉडल ऑब्जेक्ट्स की तुलना में आपके यूआरआई स्पेस में अधिक संसाधन होना चाहिए। यह आपको अपने मॉडल के काफी स्थिर भागों को उन अधिक गतिशील भागों की तुलना में एक अलग नीति के साथ कैश करने की अनुमति देता है।

उदाहरण के लिए, ऑर्डर प्रोसेसिंग सिस्टम में, डिलीवरी पता बहुत बार बदलता है, लेकिन प्रगति ट्रैकर हर कुछ मिनट बदल सकता है। दो डेटा अलग यूआरआई और विभिन्न कैश नीतियां दें।

Answer 3

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

Answer 4

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