एपीआई जाने के लिए या

Question

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

हाल ही में, हमारे डेटा पर बाहरी (जैसे हमारी कंपनी नहीं बल्कि बहन कंपनियों) ग्राहकों के बारे में एक विचार चल रहा है, और यह निर्णय लिया गया है कि हमें अपने डेटा से परामर्श करने के लिए केवल पढ़ने योग्य रीस्टफुल एपीआई का खुलासा करना चाहिए ।

मेरा मुद्दा है - क्या हमें अपने के लिए परियोजनाओं के लिए एपीआई का उपयोग करना चाहिए? क्या डेटाबेस में सीधी पहुंच के बजाय, "स्थानीय" परियोजनाओं के लिए भी एक विश्वसनीय API तक पहुंचने के लिए यह अधिक है? मुझे लगता है कि यह डेटा की हमारी टीम की पहुंच को एकजुट करने के मामले में भुगतान करेगा - लेकिन क्या यह अतिरिक्त राउंड-ट्रिप के लायक है? और क्या एक रीस्टफुल एपीआई प्रति सेकंड 20 या तो क्वेरी चलाने और जेएसओएन के माध्यम से परिणामों को उजागर करने की मांगों को जारी रख सकता है?

किसी भी इनपुट के लिए धन्यवाद!

Answer 1

मुझे लगता है कि स्थिरता के लिए बहुत कुछ कहना है। यदि आप अपने ग्राहकों के लिए एक एपीआई प्रदान कर रहे हैं, तो मुझे लगता है कि एक ही एपीआई का उपयोग करके आप इसे बेहतर wrt समझेंगे। अपने ग्राहकों के लिए इसका समर्थन करते हुए, आप नियमित रूप से इसका परीक्षण करेंगे (आपके रिग्रेशन टेस्ट से परे), और आप एक संदेश भेज रहे हैं कि यह आपके लिए उपयोग करने के लिए पर्याप्त है, इसलिए यह आपके ग्राहकों के लिए ठीक होना चाहिए।

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

अंत में, ऐसे प्रदर्शन प्रश्नों को वास्तव में केवल इसे मापने और मापने के द्वारा संबोधित किया जा सकता है। शायद यह प्रोटोटाइप एपीआई सिस्टम को एक साथ खटखटाया जा रहा है और इसे लोड के तहत पढ़ रहा है?

Answer 2

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

Answer 3

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

मत भूलना - आप फ़ाइल सिस्टम, मेमोरी, या memcached (या किसी अन्य सेवा) का उपयोग कर एपीआई कॉल को कैश भी कर सकते हैं। जहां डेटासेट नहीं बदला गया है (अपडेटेड_ट या ईटैग के साथ जांचें) आप जबरदस्त गति सुधार के लिए कैश किए गए संस्करणों को आसानी से वापस कर सकते हैं। मैंने हाल ही में किए गए एक आवेदन में ईटैग के अलावा एचटीएमएल लोड समय 1.6 सेकंड से 60 एमएस तक देखा।

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

Answer 4

मैं एक प्रोजेक्ट के लिए एक ही चीज़ के बारे में सोच रहा हूं, जिसे मैं शुरू करने वाला हूं, चाहे मुझे एपीआई के ग्राहक के रूप में जमीन से मेरा रेल ऐप बनाना चाहिए या नहीं।

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

उस के शीर्ष पर, आप भी मिलता है:

• बेहतर testability: अपने पूरे व्यापार तर्क ब्लैक बॉक्स बुनियादी HTTP resquest/प्रतिक्रिया के साथ परीक्षण योग्य है। हेडलेस ब्राउज़र/सेलेनियम केवल एप्लिकेशन-विशिष्ट व्यवहार के लिए ज़िम्मेदार हो जाते हैं;
• फ़्रंट-एंड आजादी: आप न केवल डेटाबेस प्रतिनिधित्व को बदलने के लिए स्वतंत्र हो जाते हैं, आप अपने पूरे फ्रंट एंड को बदलने के लिए स्वतंत्र हो जाते हैं, वेनिला रेल-साथ-एचटीएमएल-एंड-पेज-रीलोड्स से छिड़कने के लिए, अजाक्स, शुद्ध जावास्क्रिप्ट को पूर्ण करने के लिए (उदाहरण के लिए GWT), सभी एक ही बैक-एंड साझा करते हैं।

---

आलोचना

एक समस्या यह है कि मैं मूल रूप से इस दृष्टिकोण के साथ देखा था कि यह मुझे सभी सुविधाओं और लचीलापन है कि ActiveRecord प्रदान करता है, संघों, named_scopes और सभी के साथ खो कर होता था। लेकिन ActveResource के माध्यम से एपीआई का उपयोग करके बहुत सारी अच्छी चीजें वापस आती हैं, और ऐसा लगता है कि आपके पास named_scopes भी हो सकता है। संघों के बारे में निश्चित नहीं है।

अधिक की आलोचना, कृपया

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