लोग DBAL के बजाय REST API क्यों करते हैं?

Question

पिछले दो कंपनियों में मैं एक वेब ऐप के जरिए डेटा क्वेरी करने के लिए REST API के अस्तित्व में रहा हूं। अर्थात। इसके बजाय वेब ऐप एसक्यूएल करने के बजाय सीधे इसे एक रिस्ट एपीआई कहते हैं और यह एसक्यूएल करता है और परिणाम देता है।

मेरा सवाल है ... ऐसा क्यों किया जाता है?

अगर यह तीसरे पक्ष के सामने आने वाला था तो मैं समझ सकता था। पूर्ण DB की तुलना में सीमित REST API को उजागर करना बेहतर है। लेकिन इन दोनों कंपनियों में ऐसा नहीं है।

मुझे यह सुझाव दिया गया है कि इन REST API से DBMS के बीच स्विच करना आसान हो जाता है। लेकिन यह एक डेटाबेस अमूर्त परत (DBAL) की बात नहीं है? हो सकता है कि आप ORM का उपयोग अपने DBAL के रूप में करते हैं या हो सकता है कि आप सिर्फ कच्चा SQL लिख सकते हों और आपके DBAL ने DB विशिष्ट सामान का उपयुक्त अनुवाद किया हो (जैसे MSSQL के लिए MySQL से TOP के लिए LIMIT का अनुवाद करें)।

किसी भी तरह से यह मुझे अनावश्यक लगता है। और मुझे लगता है कि यह मुद्दों को और अधिक कठिन बना देता है। यदि वेब ऐप पर एक रिपोर्ट गलत नंबर दे रही है तो आप SQL क्वेरी को डंप नहीं कर सकते हैं - आपको REST URL को डंप करना होगा और फिर उस प्रोजेक्ट में जाएं जो REST API के रूप में काम कर रहा है और SQL को उसमें से निकाल सकता है। तो यह परोक्ष की एक अतिरिक्त परत है जो नैदानिक ​​प्रक्रिया को धीमा कर देती है।

Comments

ऐसा लगता है कि आपने केवल उन ऐप्स के साथ काम किया है जो मूल रूप से CRUD-- हैं- कुछ उपयोगकर्ता प्रपत्रों के साथ डेटा दर्ज करते हैं और अन्य उपयोगकर्ता डेटा को समान प्रपत्रों या रिपोर्ट प्रिंट आउट के साथ पढ़ते हैं? यदि आपने कभी ऐसी प्रणाली के साथ काम नहीं किया है जिसमें एक जटिल और परिष्कृत डोमेन मॉडल की आवश्यकता है, तो मैं देख सकता हूं कि आपके पास उस विशेष मानसिकता कैसे होगी। कई अनुप्रयोगों के लिए सामान करने के लिए अप्रत्यक्ष की अतिरिक्त परत की आवश्यकता होती है।

— रिबॉल्डएडीडी

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

— न्यूबर्ट

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

— रिबेल्डएडीडी

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

— gbjbaanb

@gbjbaanb: मेरा कहना है कि वेबसर्वर बाकी सर्वर के माध्यम से डेटा तक पहुंच सकता है, इसलिए यदि वेबसर्वर को हैक किया जाता है, तो हमलावर बाकी सर्वर को हैक किए बिना डेटा को बाकी सर्वर के माध्यम से भी एक्सेस कर सकता है।

— जैक्सबी

Answer 1

यदि आप किसी क्लाइंट को सीधे डेटाबेस तक पहुँचने की अनुमति देते हैं - जो वे करते हैं, यहाँ तक कि डेटाबेस एब्सट्रैक्शन लेयर के साथ, तो:

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

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

Answer 2

आप सही हैं, वेब ऐप और डेटाबेस के बीच REST API लेयर शुरू करने का कोई स्पष्ट लाभ नहीं है, और इसकी जटिलता और प्रदर्शन ओवरहेड में लागत है।

आपके विरोधाभासी उत्तर मिलने का कारण यह है कि आपकी वास्तुकला में 'ग्राहक' क्या है, इस बारे में भ्रम है।

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

लेकिन कुछ अन्य आर्किटेक्चर हैं जहां एक REST API का अर्थ है:

• यदि आपके पास डेटाबेस तक पहुँचने वाले कई ग्राहक हैं - यानी एक ही वेब ऐप नहीं, बल्कि एक ही डेटाबेस तक पहुँचने वाले कई स्वतंत्र वेब ऐप। डेटा मॉडल, कैशिंग आदि को साझा करने की अनुमति देने के लिए एक सामान्य REST इंटरफ़ेस बनाने में लाभ हो सकता है। यकीन है कि आप एक ही DAL पुस्तकालयों को साझा करके कुछ लाभ प्राप्त कर सकते हैं, लेकिन अगर अलग-अलग भाषाओं में और अलग-अलग भाषाओं में ऐप विकसित किए गए हैं, तो यह काम नहीं करेगा। प्लेटफार्मों। यह उद्यम प्रणालियों में आम है।

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

• यदि आपके पास जावास्क्रिप्ट कोड है जो सीधे सर्वर से डेटा प्राप्त करता है, तो आपको किसी भी मामले में REST API जैसा कुछ चाहिए।

Comments

मुझे आपका उत्तर पसंद आया लेकिन मेरे पास कुछ और प्रश्न हैं जो इसके साथ आते हैं। अमूर्तता की एक और परत की शुरूआत के साथ प्रदर्शन के नुकसान के बारे में क्या? इसके अलावा, यह विफलता का एकल बिंदु नहीं बनाता है (यदि यह सब कुछ नीचे चला जाता है) और संभव अड़चन (प्रत्येक एप्लिकेशन पूल से डीबी कनेक्शन की प्रतीक्षा कर रहा है)?

— sactiw

@ सैटिच: मुझे ठीक से समझ में नहीं आ रहा है कि आप क्या पूछ रहे हैं, क्या आप अधिक विशिष्ट हो सकते हैं? क्या आप REST टियर के साथ या उसके बिना एकल-बिंदु-विफलता के बारे में पूछ रहे हैं?

— जैक्सबी

अतिरिक्त परत का उपयोग हो सकता है यदि आपके पास इसके साथ संचार करने वाले एक से अधिक ऐप हैं

— ईवान

@ ईवान: हाँ, यह मैं पहली बुलेट पॉइंट में बताता हूं।

— जैक्सबी

@JacquesB मान लें कि कई वेब-ऐप एक ही DB साझा करते हैं, लेकिन एक ही डेटा यानी प्रत्येक उस DB के डेटा के एक अलग सेट पर CRUD संचालन नहीं करते हैं, मूल रूप से सही अर्थों में डेटा का कोई साझाकरण नहीं है। तो क्या रेस्टफुल पर्सिस्टेंस फ्रेमवर्क के पीछे एप्स डालने से कोई मतलब होता है (यह भी मान लें कि DB प्रश्नों में अच्छा स्तर प्रदान करता है)? इसके अलावा, क्या यह ढांचा एक अड़चन के साथ-साथ इसके माध्यम से बातचीत करने वाले इतने सारे वेब-ऐप के लिए विफलता का एकल बिंदु नहीं होगा?

— sactiw

Answer 3

चेतावनी: बड़ी पोस्ट, कुछ राय, अस्पष्ट 'क्या आपके लिए सबसे अच्छा काम करता है' निष्कर्ष

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

प्लेटफ़ॉर्म स्वतंत्रता और रखरखाव

यदि आपके पास एक डेटाबेस है, और आप उस डेटाबेस के साथ बातचीत करने के लिए एक पायथन लाइब्रेरी लिखते हैं, और हर कोई उस लाइब्रेरी में डेटाबेस के साथ बातचीत करने के लिए खींचता है, तो यह बहुत अच्छा है। लेकिन मान लीजिए कि आपको अचानक एक मोबाइल ऐप लिखने की आवश्यकता है, और उस मोबाइल ऐप को अब डेटाबेस से भी बात करनी होगी। और आपके iOS इंजीनियर पायथन का उपयोग नहीं करते हैं, और आपके एंड्रॉइड इंजीनियर पायथन का उपयोग नहीं करते हैं। हो सकता है कि iOS लोग Apple की भाषाओं का उपयोग करना चाहते हैं और Android इंजीनियर जावा का उपयोग करना चाहते हैं। फिर आप 3 अलग-अलग भाषाओं में अपने डेटा एक्सेस लाइब्रेरी को लिखना और उसे बनाए रखना चाहते हैं। हो सकता है कि आईओएस और एंड्रॉइड देवता एक्समरीन की तरह कुछ का उपयोग करने का निर्णय लेते हैं ताकि वे उस कोड को अधिकतम कर सकें जो वे साझा कर सकते हैं। बिल्कुल सही, सिवाय इसके कि आप अभी भी अपने डेटा एक्सेस लाइब्रेरी को .NET में पोर्ट करने जा रहे हैं। और फिर आपकी कंपनी ने सिर्फ दूसरी कंपनी खरीदी जो ' s वेब एप्लिकेशन एक असमान लेकिन संबंधित उत्पाद है, और व्यवसाय आपकी कंपनी के प्लेटफ़ॉर्म से कुछ डेटा को नए अधिग्रहित सहायक के प्लेटफ़ॉर्म में एकीकृत करना चाहता है। केवल एक ही समस्या है: सहायक एक स्टार्ट-अप था और डार्ट में उनके आवेदन के थोक को लिखने का फैसला किया। इसके अलावा, जो भी कारण (आपके नियंत्रण से परे के कारण हैं) जो मोबाइल टीम थी जो ज़मरीन को पायलट कर रही थी, उन्होंने फैसला किया कि यह उनके लिए नहीं है, और वे मोबाइल उपकरणों के लिए विशेष उपकरण और भाषाओं का उपयोग करेंगे, जिनके लिए वे विकसित हो रहे हैं। लेकिन जब आप उस चरण में थे, तब आपकी टीम ने आपके डेटा एक्सेस लाइब्रेरी के एक बड़े हिस्से को .NET में पहले ही डिलीवर कर दिया था, और कंपनी की एक अन्य टीम कुछ पागल सेल्सफोर्स इंटीग्रेशन सामान लिख रही थी और .NET के सभी काम करने का फैसला किया। के लिए पहले से ही एक डेटा एक्सेस लाइब्रेरी थी।

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

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

TLDR; डेटा एक्सेस लॉजिक को केंद्रीकृत करना और बहुत पतले HTTP क्लाइंट्स को बनाए रखना आसान है, क्योंकि डेटा एक्सेस लॉजिक को प्रत्येक एप्लिकेशन को वितरित करना है, जिसे डेटा एक्सेस करने की आवश्यकता है। वास्तव में, आपका HTTP क्लाइंट मेटा-डेटा से भी उत्पन्न हो सकता है। बड़े सिस्टम में, REST API आपको कम कोड बनाए रखने देता है

प्रदर्शन और मापनीयता

कुछ लोग यह मान सकते हैं कि पहले वेब सेवा के माध्यम से जाने के बजाय सीधे डेटाबेस से बात करना अधिक तेज़ है। यदि आपके पास केवल एक आवेदन है, तो यह निश्चित रूप से सच है। लेकिन बड़ी प्रणालियों में, मैं भावना से असहमत हूं। आखिरकार, कुछ स्तर पर, डेटाबेस के सामने कुछ प्रकार के कैश डालने के लिए यह बहुत फायदेमंद होने वाला है। शायद आप हाइबरनेट का उपयोग कर रहे हैं, और L2 कैश के रूप में एक Infinispan ग्रिड स्थापित करना चाहते हैं। यदि आपको अपने अनुप्रयोगों से अलग अपनी वेब सेवा को होस्ट करने के लिए 4 गोमांस सर्वरों का एक समूह मिला है, तो आप एक अंतर्निहित टोपोलॉजी के साथ तुल्यकालिक प्रतिकृति को चालू कर सकते हैं। यदि आप इसे 30 एप्लिकेशन सर्वरों के क्लस्टर पर रखने का प्रयास करते हैं, तो उस सेटअप में प्रतिकृति चालू करने का ओवरहेड बहुत अधिक होगा, इसलिए ' या तो एक वितरित मोड में या किसी प्रकार के समर्पित टोपोलॉजी में इन्फिनस्पैन को चलाना होगा, और अचानक हाइबरनेट को कैश से पढ़ने के लिए नेटवर्क पर बाहर जाना होगा। इसके अलावा, Infinispan केवल जावा में काम करता है। यदि आपके पास अन्य भाषाएं हैं, तो आपको अन्य कैशिंग समाधानों की आवश्यकता होगी। डेटाबेस तक पहुँचने से पहले आपके एप्लिकेशन से आपकी वेब सेवा पर जाने का नेटवर्क ओवरहेड बहुत अधिक जटिल कैशिंग समाधानों का उपयोग करने की आवश्यकता से जल्दी भर जाता है जो आमतौर पर अपने स्वयं के ओवरहेड के साथ आते हैं।

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

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

TLDR; अपने डेटा एक्सेस को ट्यून करना, स्केल करना और कैश करना आसान है जब यह एक ऐसी चीज़ है जो किसी एकल समर्पित वेब सेवा के अंदर होती है, तो यह तब होती है जब यह कुछ ऐसा होता है जो विभिन्न भाषाओं और तकनीकों का उपयोग करके कई अलग-अलग अनुप्रयोगों में होता है।

अंतिम विचार

कृपया इस सोच से दूर न हों "अरे वाह, मुझे हमेशा अपना डेटा प्राप्त करने के लिए REST API का उपयोग करना चाहिए" या "यह बेवकूफ कहना चाह रहा है कि हम इसे गलत कर रहे हैं क्योंकि हमारा वेब ऐप डेटाबेस से सीधे बात करता है, लेकिन हमारा सामान ठीक काम करता है! " । मैं जो प्रमुख बिंदु बनाने की कोशिश कर रहा हूं वह यह है कि विभिन्न प्रणालियों और विभिन्न व्यवसायों की अलग-अलग आवश्यकताएं हैं; बहुत सारे मामलों में, अपने डेटाबेस के सामने REST API लगाना वास्तव में मायने नहीं रखता है। यह एक अधिक जटिल वास्तुकला है जिसे उस जटिलता को सही ठहराने की आवश्यकता है। लेकिन जब जटिलता का वारंट होता है, तो REST API होने में एक टन लाभ होता है। विभिन्न चिंताओं को तौलना और अपने सिस्टम के लिए सही दृष्टिकोण का चयन करने में सक्षम होना एक अच्छा इंजीनियर बनाता है।

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

स्रोत: http://alistair.cockburn.us/Hexagonal+altecture https://github.com/brettwooldridge/HikariCP/wiki/About-Pool-Sizing

Comments

बहुत अच्छा जवाब, पढ़ने लायक। इस महान उत्तर को लिखने के लिए समय निकालने के लिए धन्यवाद!

— डोमिनिक

Answer 4

यदि मैं सही ढंग से समझता हूं कि DBAL क्या है , तो इसका उत्तर यह है कि एक REST इंटरफ़ेस आपको अपने ग्राहकों के लिए किसी भी भाषा का उपयोग करने की अनुमति देता है, जबकि DBAL एक पुस्तकालय है जो आपको अपने ग्राहकों के लिए एक ही भाषा का उपयोग करने की अनुमति देता है।

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

अधिक सार शब्दों में, आप स्वयं इस प्रश्न का उत्तर दे रहे हैं:

तो यह परोक्ष की एक अतिरिक्त परत है जो नैदानिक ​​प्रक्रिया को धीमा कर देती है

... चूँकि यह प्रसिद्ध उपहास है जो बताता है: "कंप्यूटर विज्ञान में सभी समस्याओं को एक अन्य स्तर पर अप्रत्यक्ष रूप से हल किया जा सकता है"। :)

Answer 5

सिर्फ इसलिए कि आप एक ही कंपनी के अंदर हैं इसका मतलब यह नहीं है कि आपको हर किसी को सब कुछ उजागर करना चाहिए। REST API एक स्पष्ट अनुबंध के साथ एक कंपनी में टीमों के बीच सीमित उपभोक्ता / प्रदाता संबंध को परिभाषित करने का एक तरीका है। अमेज़ॅन इस संगठन के रूप में अग्रणी रहा है।

एपीआई आपको अमूर्तता की एक परत भी प्रदान करते हैं, जिससे आप मुहावरों के एक विशिष्ट सेट का उपयोग कर सकते हैं - आप जरूरी नहीं कि अपने उपभोक्ताओं से उन्हीं शब्दों में बात करें जो आपके डेटाबेस में उपयोग किए जाते हैं। आप भी जरूरी नहीं कि हर उपभोक्ता से इसी तरह बात करें।

Answer 6

आप सोच रहे हैं कि REST डेटाबेस क्वेरीज़ के लिए है और यह नहीं है। REST इस समय किसी चीज़ की स्थिति का प्रतिनिधित्व करता है। REST के उपयोग से एक प्रतिनिधित्व बदल जाता है या पुनः प्राप्त हो जाता है लेकिन यह सब है। यदि वह स्थिति डेटाबेस द्वारा उपलब्ध हो जाती है, तो इससे कोई फर्क नहीं पड़ता और कोई परवाह नहीं करता क्योंकि HOW जो प्रतिनिधित्व करता है वह REST का हिस्सा नहीं है और न ही डेटाबेस प्रश्न हैं।

Comments

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

— न्यूबर्ट

@neubert इंटरनेट पर DBAL काम करता है जैसे REST करता है?

— रॉब

ज़रूर। आप IP पते / डोमेन नाम / पोर्ट का उपयोग करने के लिए MySQL को बता सकते हैं जो इंटरनेट पर किसी अन्य कंप्यूटर से संबंधित है। आप एसएसएच टनलिंग का उपयोग कर सकते हैं और साथ ही (मेरा मानना ​​है कि) एसएसएल के रूप में अच्छी तरह से। संभवत: इसी तरह अन्य डीबीएमएस का काम।

— न्यूबर्ट

@neubert: उस मामले में, बाकी एपीआई है एक DBAL, हैं ना?

— रेमकोगर्लिच

@RemcoGerlich - सुनिश्चित करें, लेकिन आपके DBAL के रूप में REST API का उपयोग एक मध्य परत को जोड़ सकता है जो अनावश्यक है और समस्याओं के निदान में बाधा उत्पन्न करता है। मेरा मतलब है, अगर आप DBAL की पर्याप्त व्यापक परिभाषा का उपयोग करने वाले हैं तो आप Google SERP के DBAL होने पर विचार कर सकते हैं। Google के सर्वर से पृष्ठांकित डेटा प्राप्त करने के लिए आपको बस HTML को पार्स करना है ...

— neubert