मुझे अपने डेटाबेस में बाहरी लोगों को क्यों नहीं पहुंचना चाहिए?

Question

आज बहुत सारी साइटों में एपीआई हैं जो उपयोगकर्ताओं को साइट से डेटा प्राप्त करने के लिए XML या JSON को HTTP HTTP अनुरोध का उपयोग करने की अनुमति देती हैं। Flickr और del.icio.us एपीआई के साथ साइटों का उदाहरण हैं। इन एपीआई को सर्वर को डेटाबेस तक पहुंचने की आवश्यकता होती है, और फिर परिणाम को एक्सएमएल या जेएसओएन के रूप में आउटपुट किया जाता है।

हमें इस अनुवाद की आवश्यकता क्यों है? डेटाबेस पर उपयोगकर्ता क्यों न बनाएं (उदाहरण के लिए MySQL)? उपयोगकर्ता को डेटाबेस तक सीमित पहुंच दी जाएगी, केवल चयन करने की अनुमति दी जा रही है, और केवल उन तालिकाओं में कुछ निश्चित तालिकाएं और कुछ कॉलम दिए जाएंगे। क्या यह सर्वर के लिए बहुत अधिक कुशल नहीं होगा (इसे HTTP अनुरोध से निपटना नहीं होगा), और डेवलपर्स के लिए यह आसान होगा, जो अब उन्हें आवश्यक डेटा तक पहुंच सकते हैं, जिस तरह उन्हें इसकी आवश्यकता है।

Answer 1

सुरक्षा विचारों को एक तरफ, ताकि आप अपने ग्राहकों को प्रभावित किए बिना अपनी डेटाबेस संरचना बदल सकें। इसके अलावा, खराब गठित प्रश्न को अपने सर्वर से जोड़ते हैं, न कि ग्राहक।

Answer 2

क्या आप किसी दुर्भावनापूर्ण व्यक्ति को एक सुपर-जटिल SQL क्वेरी तैयार करने से रोक सकते हैं जो आपके डेटाबेस के CPU को 100% पर चिपकाएगा? क्या आप कई निर्दोष प्रोग्रामर को अपर्याप्त प्रश्नों को तैयार करने से रोक सकते हैं जिन्हें कभी अनुकूलित नहीं किया जाएगा जो वही काम करेगा?

Answer 3

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

-don

Answer 4

पोर्टेबिलिटी भी। आइए लाइसेंसिंग कारणों और स्केलिंग के लिए कहें कि आप MSSQL से MySQL तक स्थानांतरित करने का व्यवसाय निर्णय लेते हैं। सिंटेक्स बिल्कुल समान नहीं है और आपके क्लाइंट को सभी को अपना कोड बदलना होगा।

बस इसे बंद करने और कार्यान्वयन को दूर रखने के लिए बहुत बेहतर है। किसके कहने के लिए आप बोतलबंदों पर प्रशिक्षित बंदर खरोंच के निशान का उपयोग कर आवेदन की स्थिति को कायम नहीं रख रहे हैं?

Answer 5

यह 'आप क्यों नहीं' सवाल से ज्यादा 'क्यों नहीं' नहीं है। एचटीटीपी अनुरोधों को संभालने के लिए उपयोगकर्ता द्वारा उपयोग किए जाने वाले सभी डेटा को अनुमति देने या अस्वीकार करने के लिए पूर्ण नियंत्रण के लिए एक छोटा सा जुर्माना है। इसके अलावा, भविष्य में डेटा की प्रकृति/मात्रा/सुरक्षा स्तर में परिवर्तन होना चाहिए, तो आप कुल पहुंच की अनुमति के मुकाबले जेएसओएन/एक्सएमएल प्रतिक्रिया से बेहतर होंगे।

Answer 6

एक एपीआई:

• यह आसान montior को और नियंत्रण के उपयोग (लागू करने डीबी उपयोगकर्ताओं के लिए 'प्रति एक्स सीमित प्रश्नों' कठिन हो सकता है)
• हो सकता है की तुलना में उपयोगकर्ता के लिए सरल संरचनाओं पेश करने के लिए अनुमति देता है बनाता है डीबी में प्रयोग किया जाता है।
• मतलब है कि उपयोगकर्ता को आपकी डीबी संरचना को समझने की आवश्यकता नहीं है।
• डीबी पोर्टेबिलिटी की अनुमति देता है। (ओह आप बड़े हो गए हैं और अब इसे कार्यान्वित करने की जरूरत है: शेरिंग, बिगटेबल पर जाएं, आदि - एक एपीआई के साथ उपयोगकर्ता को जानने की आवश्यकता नहीं है)
• अनुरोधों के कैशिंग को अलग (बेहतर?/चर?) की अनुमति देता है ।
• मतलब आपको अतिरिक्त डीबी उपयोगकर्ताओं के लिए भुगतान नहीं करना है (यदि डीबी लाइसेंस प्राप्त है।)

Answer 7

ठेका कोडिंग - एपीआई के साथ, आप बाहरी लोगों उनमें से उपयोग करने को प्रभावित किए बिना उनके पीछे सब कुछ बदल सकते हैं। यहां आप उन्हें केवल MySQL नहीं बल्कि आपके स्कीमा

कैशिंग - उन्हें किसी भी प्रश्न की अनुमति देने से लगभग http पर अनुमानित प्रश्नों को कैशिंग करने के लिए किसी भी अवसर को हटा दिया जा सकता है। यह अक्सर संख्या एक बाधा, डेटाबेस को हटाने का नंबर एक तरीका है।

सुरक्षा - इस दृष्टिकोण के साथ, दुर्घटना से भी सेवा हमले से इंकार करने के लिए यह आसान होगा। नहीं करने के लिए इस तथ्य का उल्लेख आप डेटा स्तर पर है, जो अक्सर एक प्रतिबंधित क्षेत्र है जहाँ सुरक्षा कड़ी कर दी गई किया जा सकता है

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

Answer 8

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

Answer 9

सुरक्षा नंबर 1 कारण है लेकिन मुझे उम्मीद है कि उन कारण स्पष्ट हैं। खराब प्रश्नों के साथ बहुमूल्य संसाधनों का उपयोग करने वाला उपयोगकर्ता एक और अच्छा कारण है।

हालांकि, इसके अलावा, एक अमूर्त परत क्यों?

• क्या आप कभी भी गति का निदान करने या डीबग करने में सहायता के लिए डेटाबेस प्रश्नों में कुछ लॉगिंग जोड़ना चाहते हैं?
• क्या आप कभी भी MySQL से एमएस एसक्यूएल में जा सकते हैं या इसके विपरीत जहां शुद्ध एएनएसआई के अलावा एसक्यूएल टूट सकता है?
• क्या ग्राहक को वास्तव में अधिक तार्किक अमूर्तता के बजाय अपनी स्कीमा सीखनी है?
• जब कोई नया प्रोग्रामर सामान्यीकरण सीखता है और अब आपकी सावधानीपूर्वक संतुलित denormalizations सहित आपकी पूरी स्कीमा देख सकता है, तो क्या आप हर अनौपचारिक आलोचना के साथ रखना चाहते हैं?
• जब एक और अनुभवी डीबी व्यक्ति सुधार को इंगित करता है, तो क्या आप अपनी पुरानी स्कीमा से फंसना चाहते हैं?

एपीआई का उपयोग क्यों करें एब्स्ट्रैक्शन का उपयोग क्यों करें और मेरी सूची यहां सतह को मुश्किल से खरोंच करती है।

Answer 10

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

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