आंतरिक और बाहरी एपीआई वास्तुकला

Question

जिस कंपनी के लिए मैं काम करता हूं, वह एक सफल सास उत्पाद को बनाए रखती है, जो वर्षों में "व्यवस्थित रूप से" बढ़ता है। हम नए उत्पादों के एक सूट के साथ लाइन का विस्तार करने की योजना बना रहे हैं जो मौजूदा उत्पाद के साथ डेटा साझा करेंगे। इसका समर्थन करने के लिए, हम व्यावसायिक तर्क को एक ही स्थान पर समेकित करना चाहते हैं: एक वेब सेवा परत। WS परत द्वारा उपयोग किया जाएगा:

• वेब अनुप्रयोगों
• डेटा आयात करने का एक उपकरण
• अन्य क्लाइंट सॉफ़्टवेयर के साथ एकीकृत करने के लिए एक उपकरण (प्रति एपीवाई नहीं)

हम एक एपीआई भी बनाना चाहते हैं जो हमारे ग्राहकों द्वारा उपयोग किया जा सकता है जो इसे अपने स्वयं के एकीकरण बनाने के लिए उपयोग करने में सक्षम हैं। हम निम्नलिखित प्रश्न से जूझ रहे हैं:

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

एक जैसी स्थिति में दूसरों ने क्या किया है?

Comments

यदि आप SOA के लिए एक अच्छा ढाँचा खरीदते हैं, तो यह सारी बहस मूक है। क्या आप अपने स्वयं के SOA ढांचे को रोल करने की योजना बना रहे हैं? क्यों? यदि यह एक सफल उत्पाद है, तो Oracle से JCAPS का लाइसेंस क्यों नहीं? या IBM से WebSphere? तब WS लेयर की सुरक्षा सर्वव्यापी और पारदर्शी हो जाती है।

— एस.लॉट

@ S.Lott यह वास्तव में एक SOA परत लिखने में मुश्किल नहीं है। उन प्लेटफार्मों में से कोई भी REST- आधारित नहीं हैं; यह 2012 है न? वे आवाज भयानक 'enterprisey'।

— इवान प्लाइस

आपके डोमेन मॉडल के शीर्ष पर एक सेवा परत क्यों नहीं है, तो आप आंतरिक स्रोत के साथ समान सेवाओं का उपयोग कर सकते हैं।

— मैब्यूलेज़

Answer 1

हमेशा अपना खुद का डॉगफूड खाना अच्छा होता है। प्रमाणीकरण और प्राधिकरण के लिए कुछ ओवरहेड में कारक होने पर भी एक एपीआई को दो से अधिक बनाए रखने के लिए सरल होना चाहिए।

Comments

आप जिस तरह से डालते हैं मुझे पसंद है। दो अलग-अलग परतों के होने का मतलब है कि भविष्य में चीजों को बदलने के लिए दो बार भविष्य में कई बार, अतिरिक्त परीक्षण, और बहुत सारी सामान्य पागलपन यह जानने की कोशिश करते हैं कि चीजें सिंक से बाहर क्यों निकलीं। अगर आपके पास अपना जवाब देने के लिए पर्याप्त प्रतिष्ठा है, तो मैं :)

— ड्रू गुडविन

Answer 2

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

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

Comments

मुझे लगता है कि हम यहां समझौते में हैं। आंतरिक उपयोगकर्ताओं को कार्यक्षमता के सुपरसेट को प्रतिबंधित करने के लिए सुरक्षा परत का उपयोग करें। इस तरह, आपको एपीआई तक पहुँचने के लिए एक एपीआई लेकिन कई स्तरों की अनुमति मिल गई है।

— Aneurysm9

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

— एजेबी

Answer 3

मैंने पहले (कई बार) इसका सामना किया है और जो मैंने पसंद किया है, वह है:

बीएल को वेबसाइट से बाहर ले जाएं। वेबसाइट को एपीआई का उपभोक्ता बनाएं। वेबसाइट को अपने एपीआई के कुछ अन्य ग्राहक के रूप में समझो। आपकी एपीआई सेवा है।

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

आश्वस्त नहीं?

प्रतिमान को एक कदम आगे बढ़ाएं ...

फोन ऐप एक प्लेटफ़ॉर्म पर चल रहा है, जहाँ बायटेकोड निष्पादित होता है, ऐप फ़ोन में रहता है और HTTP / MSN विंस के माध्यम से एपीआई सेवाओं का उपभोग करता है।

वेबसाइट एक ऐप है जो एक प्लेटफ़ॉर्म पर चल रहा है जहां HTML + जावास्क्रिप्ट निष्पादित किया जाता है, ऐप एक ब्राउज़र में रहता है और HTTP / JSON के माध्यम से एपीआई सेवाओं का उपभोग करता है।

वही वही!

टेबलेट, टीवी, अन्य फ़ोन प्लेटफ़ॉर्म, प्लगइन्स, थर्ड पार्टी ऐप्स, मैशअप, ... तक बढ़ाएँ

विभिन्न उपयोगकर्ता के बहुत सारे अनुभव सभी एक आम एपीआई में खामियों को दूर करते हैं।

आपका ऐप एपीआई है। वेबसाइट सिर्फ एक ग्राहक है (कई की)

Comments

समझने कि एपीआई है पूरे अनुप्रयोग परत, और विभिन्न संस्करणों (OS, ब्राउज़र, टेबलेट, फ़ोन) एपीआई का सिर्फ ग्राहकों रहे हैं मुझे एक हा करने के लिए मिल गया है! अभी अभी।

— एजेबी

Answer 4

एक एपीआई का उपयोग करें

यदि आप सेवा API को REST परत के रूप में कार्यान्वित कर रहे हैं, तो केवल उन मार्गों पर प्रमाणीकरण जोड़ें, जो सुरक्षित हैं।

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

कुछ ऐसा सोचें जैसे Node.js / Express, python / pylons, python / google app engine, आदि।

मैंने हाल ही में इसे Google App Engine पर REST / Datastore API के लिए लागू किया है और मुझे नहीं लगता कि यह आसान हो सकता था। नियंत्रकों को कक्षाओं के रूप में लागू किया जाता है और उनके बाद के HTTP अनुरोध (यानी GET / POST / PUT / DELETE) उन वर्गों के तरीकों के रूप में लागू किए जाते हैं। मैं एक डेकोरेटर के रूप में बुनियादी-कार्यान्‍वयन को लागू करने में कामयाब रहा। इसने @basicAuth डेकोरेटर को संलग्न करने के लिए एक अनुरोध को प्रमाणीकरण की आवश्यकता को सरल बना दिया।

इस तरह, मैं आने वाले GET अनुरोधों को सार्वजनिक कर सकता हूं कि उस मॉडल के समान नियंत्रक पर POST / PUT / DELETE अनुरोधों के लिए एक सामान्य आवश्यकता जोड़ सकता है।

यदि आप जानते हैं कि REST में कैसे बोलना है, तो जीवन बहुत आसान हो जाता है क्योंकि REST का समर्थन पहले से ही कभी वेबसर्वर (यानी HTTP केवल REST API का एक प्रकार) है। यदि आप तार में बहुत सारा डेटा भेज रहे हैं, तो आप पारदर्शी gzip संपीड़न का विकल्प भी चुन सकते हैं।

Answer 5

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

Comments

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

— न्यूटॉपियन