कन्वेंशन क्यों कहता है कि डीबी टेबल के नाम विलक्षण हैं, लेकिन रेस्टफुल रिसोर्स बहुवचन हैं?

Question

यह एक सुंदर स्थापित कन्वेंशन है जो डेटाबेस टेबल के नाम, SQL में कम से कम, एकवचन होना चाहिए। इस सवाल और चर्चा कोSELECT * FROM user; देखें ।

यह भी एक बहुत स्थापित सम्मेलन है कि RESTful एपीआई संसाधन नाम बहुवचन होना चाहिए। GET /users/123और यह एकPOST /users देखें ।

सरलतम डेटाबेस-समर्थित API में, URL में संसाधन का नाम तालिका होगा, और URL में डेटा तत्व और अनुरोध / प्रतिसाद निकाय DB में स्तंभों पर सीधे मैप करेंगे। वैचारिक रूप से, मुझे इस सैद्धांतिक एपीआई के माध्यम से डेटा पर काम करने और सीधे SQL के माध्यम से उस पर काम करने के बीच कोई अंतर नहीं दिखता है। और उस वजह से, के बीच सम्मेलनों के नामकरण में अंतर userऔर usersमेरे लिए कोई मतलब नहीं है।

बहुवचन में अंतर कैसे उचित हो सकता है, जब वैचारिक रूप से, REST API और SQL एक ही काम कर रहे हों?

Comments

DB तालिका के नामकरण में कोई एकल सम्मेलन नहीं है और न ही Restful संसाधन का नामकरण, जिसका हर कोई अनुसरण करता है। इसके विपरीत, कई सम्मेलन हो सकते हैं। यह आश्चर्य की बात नहीं है कि कुछ टकरा सकते हैं।

— एरिक किंग

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

— ग्रैंडमास्टरबी

@GrandmasterB कन्वेंशन मौजूद है और इसका मूल कोडक के संबंधपरक मॉडल में है जहां "संबंध" (जो तालिकाओं बन जाते हैं, रिश्तों को स्वीकार करने के लिए नहीं) में एकवचन नाम होते हैं क्योंकि एक संबंध चीजों की एक सूची है जिसमें कई चीजों की सूची नहीं है। प्रत्येक संबंध एक सूची है। संबंध मॉडल डोमेन इकाइयां। कोड्स के रिलेशनल मॉडल में एंटिटीज के नाम एकवचन हैं। इसके बारे में प्रचुर साहित्य है क्योंकि यह कहना है कि यह अस्तित्व में नहीं है। लेकिन अगर आप चाहें तो बहुवचन नामों का उपयोग करना आपके लिए पूरी तरह से ठीक है।

— ट्यूलेंस कॉर्डोवा

@ user61852 ऐसे लोग हैं जो सम्मेलन द्वारा इसका उपयोग कर सकते हैं। लेकिन इसका कोई मतलब नहीं है कि व्यापक रूप से उद्योग सम्मेलन का पालन किया जाए, जैसा कि इस प्रश्न को इस तरह से प्रस्तुत किया गया है, जैसे कि कैमलकेस या मार्कडाउन है।

— ग्रैंडमास्टरबी

यह भी ध्यान रखें कि REST एक डेटाबेस एक्सेस प्रोटोकॉल नहीं है। ऐसा कोई कारण नहीं है कि DB नामकरण परंपराएं (जो कभी आपके साथ जाती हैं) और URL नामकरण परंपराएं (जो कभी आपके साथ जाती हैं) कुछ भी समान होनी चाहिए, उनका एक दूसरे के साथ कुछ भी नहीं है। दो बहुत अलग डोमेन। यह अधिक समझ में नहीं आता है कि डेटाबेस एकवचन का उपयोग क्यों करते हैं और URL, विचारक की तुलना में बहुवचन का उपयोग क्यों डेटाबेस एकल का उपयोग करते हैं, लेकिन मेरे sys व्यवस्थापक अपने फ़ाइल सिस्टम निर्देशिकाओं को बहुवचन नाम देते हैं। खराब तरीके से तैयार किए गए वेब फ्रेमवर्क में लोगों को लगता है कि REST डीबी एक्सेस के साथ कुछ करना है, लेकिन यह नहीं है।

— कॉर्मैक मुलहाल

Answer 1

REST युक्ति (आप जिस भी स्तर पर जाना चाहते हैं) को डेटाबेस एक्सेस के रूप में डिज़ाइन नहीं किया गया था। यह एपीआई एक्सेस तक मानकीकरण लाने की कोशिश कर रहा है। उल्लेख किए गए SQL सम्मेलनों (चाहे आप उन्हें उपयोग करना चाहते हैं या नहीं) को एपीआई एक्सेस को ध्यान में रखते हुए डिज़ाइन नहीं किया गया था। वे SQL क्वेरी लिखने के लिए हैं।

इसलिए यहां अनपैक करने का मुद्दा वैचारिक समझ है जो एक एपीआई डेटाबेस पर सीधे मैप करता है। हम इसे कम से कम 2009 तक कम से कम एंटी-पैटर्न के रूप में वर्णित पा सकते हैं ।

मूल कारण यह बुरा है? यह वर्णन करने वाला कोड "यह ऑपरेशन मेरे डेटा को कैसे प्रभावित करता है?" क्लाइंट कोड बन जाता है ।

यह एपीआई पर कुछ बहुत भयानक प्रभाव है। (संपूर्ण सूची नहीं)

यह एपीआई को कठिन बनाता है

मैं एक नए उपयोगकर्ता को इस तरह से बनाने के लिए कदमों की कल्पना करता हूं:

1. POST /users { .. }
2. POST /usersettings { .. } कुछ डिफ़ॉल्ट मानों के साथ
3. POST /confirmemails { .. }

लेकिन आप चरण # 2 की विफलता को कैसे संभालते हैं? आपके एपीआई के अन्य ग्राहकों के लिए यह कितनी बार वही लॉजिक कॉपी-पास्ता है?

क्लाइंट की ओर से एकल ऑपरेशन के रूप में शुरू किए जाने पर ये डेटा ऑपरेशन अक्सर सर्वर साइड पर अनुक्रम करना आसान होते हैं। जैसे POST /newusersetup। DBA इसे एक संग्रहीत कार्यविधि के रूप में पहचान सकते हैं, लेकिन API ऑपरेशन का प्रभाव केवल डेटाबेस से परे हो सकता है।

एपीआई को सुरक्षित करने से निराशा का एक ब्लैक होल बन जाता है

मान लें कि आपको दो उपयोगकर्ता खातों को मर्ज करने की आवश्यकता है।

1. GET /users/1
2. PUT /users/2 { .. }
3. DELETE /users/1

आप उपयोगकर्ता विलोपन की अनुमति नहीं देते हुए मर्ज सुविधा की अनुमति के लिए उपयोगकर्ता की अनुमति कैसे सेट करने जा रहे हैं? क्या उपयोगकर्ता को DELETE /users/1तब /usersettingsभी हटा दिया जाता है जब वह मौजूद होता है?

एपीआई संचालन को उच्चतर (-से-डेटाबेस) -वेल संचालन के रूप में देखा जाना चाहिए जिससे सिस्टम में कई परिवर्तन हो सकते हैं।

रखरखाव कठिन हो जाता है

... क्योंकि आपके ग्राहक आपके डेटाबेस संरचना पर निर्भर हैं।

इस परिदृश्य के साथ मेरे अनुभव के आधार पर:

• आप मौजूदा तालिकाओं / स्तंभों का नाम बदल या निकाल नहीं सकते। यहां तक ​​कि जब वे अपने फ़ंक्शन के लिए गलत तरीके से नामित किए जाते हैं या अब उपयोग नहीं किए जाते हैं। ग्राहक टूटेंगे।
• नई सुविधाएँ मौजूदा डेटा संरचनाओं को परिवर्तित नहीं कर सकती हैं, इसलिए इसका डेटा और कार्यक्षमता अक्सर कृत्रिम रूप से अलग हो जाती है, जब यह समग्र रूप से किसी मौजूदा विशेषता के साथ होती है।
• कोड आधार धीरे-धीरे विखंडन, भ्रमित करने वाले नामों और बचे-खुचे सामान के कारण समझना कठिन हो जाता है, जिन्हें सुरक्षित रूप से हटाया नहीं जा सकता।
• सभी लेकिन तुच्छ परिवर्तन तेजी से जोखिम भरे और समय लेने वाले बनते हैं।
• सिस्टम स्थिर हो जाता है और अंततः बदल दिया जाता है।

सीधे ग्राहकों के लिए अपने डेटाबेस संरचना को उजागर न करें ... विशेष रूप से ग्राहकों को आपके पास विकास संबंधी नियंत्रण नहीं है। केवल मान्य संचालन के लिए क्लाइंट को संकुचित करने के लिए API का उपयोग करें।

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

Comments

एक अलग सवाल का जवाब देता है। ओपी सीधे तौर पर एपीआई और डीबी संस्थाओं का जुड़ाव नहीं करता है, बस दोनों संदर्भों में कुछ संस्थाओं की उपस्थिति है।

— 19

जिस प्रश्न के बारे में आप पूछ रहे हैं, उसका उत्तर देने के लिए स्वतंत्र महसूस करें।

— कासे स्पीकमैन

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

— अलुआन हदाद

इनमें से कई कारण हैं जो मैंने स्प्रिंग डेटा रेस्ट का उपयोग करना बंद कर दिया है।

— सेबेस्टियन वैन डेन ब्रोक

Answer 2

REST API और SQL "समान कार्य नहीं कर रहे हैं"

ओपी पूछता है:

बहुवचन में अंतर कैसे उचित हो सकता है, जब वैचारिक रूप से, REST API और SQL एक ही काम कर रहे हों?

आह, लेकिन टिड्डी, यह हो सकता है दिखाई देते हैं कि RESTful इंटरफेस और एसक्यूएल टेबल "ही बात कर रहे", लेकिन अच्छा प्रोग्रामिंग स्वच्छता हमेशा एक मध्यवर्ती परत है कि वहाँ हमें बताता है कि बाकी एपीआई और डेटाबेस के बीच मध्यस्थता करता है। इस बिंदु को नजरअंदाज करने के लिए सॉफ्टवेयर ज्ञान के लिए पथ से भटकना है! :)

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