क्या आपको एपीआई के रूप में अपना बैक-एंड लिखना चाहिए?

322

हमारे एमवीसी एप्लिकेशन के बारे में आज मेरी चर्चा गर्म रही। हमारे पास MVC ( ASP.NET ) में लिखी गई वेबसाइट है , और यह आमतौर पर दृश्य में कुछ करने के पैटर्न का अनुसरण करता है -> नियंत्रक से टकराता है -> नियंत्रक एक मॉडल बनाता है (एक प्रबंधक को जो डेटा मिलता है, मॉडल का निर्माण करता है) नियंत्रक विधि ही) -> मॉडल देखने जाता है -> कुल्ला और दोहराएं।

उन्होंने कहा कि हमारा कोड बहुत अधिक युग्मित था। उदाहरण के लिए, यदि हम एक डेस्कटॉप एप्लिकेशन भी चाहते हैं, तो हम अपने मौजूदा कोड का उपयोग नहीं कर पाएंगे।

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

यह विभिन्न कारणों से मेरे लिए एक बुरा विचार है।

वैसे भी मैं इस अभ्यास पर चर्चा कर सकते हैं googling द्वारा कुछ भी नहीं मिल रहा है। क्या किसी के पास पेशेवरों, विपक्षों के बारे में कोई जानकारी है, आपको क्यों, आपको क्यों नहीं पढ़ना चाहिए या आगे पढ़ना चाहिए?

मुझे लगता है कि यह एक बुरा विचार है:

यह एक एपीआई से अपने बैकएंड को चलाने के लिए बहुत सार है। आप इसे बहुत लचीला बनाने की कोशिश कर रहे हैं जो इसे एक असहनीय गड़बड़ कर देगा।
MVC में निर्मित सभी चीजें बेकार लगती हैं, जैसे भूमिकाएं और प्रमाणीकरण। उदाहरण के लिए, [अधिकृत] विशेषताएँ और सुरक्षा; आपको अपना रोल खुद करना होगा।
आपके सभी एपीआई कॉल के लिए सुरक्षा संबंधी जानकारी संलग्न करनी होगी, और आपको एक टोकन सिस्टम और व्हाट्सएप विकसित करना होगा।
आपको हर एक फंक्शन के लिए पूरा एपीआई कॉल लिखना होगा जो आपका प्रोग्राम कभी भी करेगा। बहुत ज्यादा हर विधि जिसे आप लागू करना चाहते हैं, उसे एक एपीआई से भागना होगा। प्रत्येक उपयोगकर्ता के लिए एक गेट / अपडेट / डिलीट, प्लस एक दूसरे ऑपरेशन के लिए एक संस्करण जैसे उपयोगकर्ता नाम अपडेट करें, उपयोगकर्ता को एक समूह में जोड़ें, आदि आदि और प्रत्येक एक अलग एपीआई कॉल होगा।
जब API की बात आती है तो आप इंटरफेस और अमूर्त वर्गों जैसे सभी प्रकार के उपकरण खो देते हैं। WCF जैसे स्टफ को इंटरफेस के लिए बहुत ही कठिन समर्थन है।
आपके पास एक विधि है जो एक उपयोगकर्ता बनाती है, या कुछ कार्य करती है। यदि आप 50 उपयोगकर्ता बनाना चाहते हैं, तो आप इसे केवल 50 बार कॉल कर सकते हैं। जब आप इस विधि को एक एपीआई के रूप में करने का निर्णय लेते हैं तो आपका स्थानीय वेबसर्वर नाम-पाइप इसे कनेक्ट कर सकता है और कोई समस्या नहीं - आपका डेस्कटॉप क्लाइंट इसे भी हिट कर सकता है, लेकिन अचानक आपके थोक उपयोगकर्ता निर्माण में इंटरनेट पर एपीआई को 50 बार हथौड़ा करना शामिल होगा जो isn 'अच्छा है। इसलिए आपको एक बल्क विधि बनानी होगी, लेकिन वास्तव में आप इसे सिर्फ डेस्कटॉप क्लाइंट के लिए बना रहे हैं। इस तरह, आप अंत में) अपने एपीआई को संशोधित करते हैं, जो इसके साथ एकीकृत होने पर आधारित है, और आप सीधे इसके साथ एकीकृत नहीं कर सकते हैं, बी) एक अतिरिक्त कार्य बनाने के लिए बहुत अधिक काम करते हैं।
YAGNI । जब तक आप विशेष रूप से दो पहचान वाले कामकाजी एप्लिकेशन, एक वेब और एक विंडोज एप्लिकेशन को उदाहरण के लिए लिखने की योजना नहीं बना रहे हैं, यह अतिरिक्त विकास कार्य की एक बड़ी मात्रा है।
जब आप एंड-टू-एंड के माध्यम से कदम नहीं रख सकते हैं तो डिबगिंग बहुत कठिन है।
स्वतंत्र संचालन के बहुत सारे, जिन्हें बहुत आगे और पीछे की आवश्यकता होगी, उदाहरण के लिए कुछ कोड वर्तमान उपयोगकर्ता को मिल सकते हैं, उपयोगकर्ता को व्यवस्थापक भूमिका में है, उस कंपनी को प्राप्त करें जिसे उपयोगकर्ता संबंधित है, अन्य सदस्यों की सूची प्राप्त करें, उन सभी को भेजें एक ईमेल। इसके लिए बहुत सारे API कॉल की आवश्यकता होगी, या आप जिस विशिष्ट कार्य को चाहते हैं, उसके लिए एक bespoke विधि लिखना, जहाँ bespoke पद्धति का एकमात्र लाभ गति होगा फिर भी नकारात्मक पक्ष यह होगा कि यह अनम्य होगा।
शायद कुछ और कारण ये मेरे सिर के ठीक ऊपर हैं।

यह सिर्फ मुझे लगता है जब तक आपको वास्तव में दो समान अनुप्रयोगों की आवश्यकता नहीं है, तब यह वास्तव में इसके लायक नहीं है। मैंने कभी भी ASP.NET एप्लिकेशन को इस तरह से निर्मित नहीं देखा है, आपको दो अलग-अलग एप्लिकेशन (एपीआई और आपका कोड) लिखना होगा और संस्करण को इन दोनों को भी नियंत्रित करना होगा (यदि आपका उपयोगकर्ता पृष्ठ एक नया क्षेत्र प्राप्त करता है, तो आप ' डी को एपीआई और अपने उपभोग कोड को एक साथ अपडेट करना है ताकि कोई बुरा प्रभाव न हो या इसे मजबूत रखने में बहुत सारे अतिरिक्त काम न करें)।

संपादित करें: कुछ बेहतरीन प्रतिक्रियाएं, वास्तव में यह सब क्या है का एक अच्छा विचार प्राप्त करना शुरू कर रही है। तो मेरे सवाल पर विस्तार करने के लिए, आप इस एपीआई संरचना का पालन करने के लिए एक एमवीसी ऐप कैसे तैयार करेंगे?

उदाहरण के लिए, आपके पास एक वेबसाइट है जो एक उपयोगकर्ता के बारे में जानकारी प्रदर्शित करती है। MVC के तहत, आपके पास:

देखें - (CS) HTML पृष्ठ जो एक UserViewModel नियंत्रक - कॉल्स गेटयूज़र () को प्रदर्शित करता है और एक UserViewModel बनाता है जो इसे गेट मैनेजर विधि (आपकी API की तरह) व्यू मैनेजर क्लास में भेजता है।

नियंत्रक GetUser () करता है, लेकिन आप एक डेस्कटॉप ऐप भी चाहते हैं। इसका अर्थ है कि आपके गेटअप को किसी प्रकार के एपीआई के माध्यम से उजागर करना होगा। आप एक टीसीपी कनेक्शन, या तो WCF, या शायद रिमोटिंग चाहते हैं। आप एक मोबाइल ऐप भी चाहते हैं, जो लगातार कनेक्शन के बाद से Restful होगा।

तो क्या आप हर एक के लिए एक एपीआई लिखेंगे, एक WCF वेब सेवा जिसमें एक विधि GetUser () और कोड बस होता है return new UserManager().GetUser()? और एक mvc 4 वेब एपीआई विधि जो एक ही काम करती है? अपने MVC नियंत्रक विधि में सीधे GetUser को कॉल करना जारी रखें?

या क्या आप उस समाधान को चुनेंगे जो तीनों (वेब एप रीस्ट सर्विस) के लिए काम करेगा और उस पर सब कुछ बनाएगा, इसलिए सभी तीन एप्स एपीआई कॉल (एमवीसी वाले, लोकल मशीन को) करते हैं।

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

संपादित करें 2: अधिक सामान पढ़ने के बाद, मैंने नीचे टिप्पणी की है कि मुझे लगता है कि यह समझा सकता है। सवाल थोड़ा मुश्किल सवाल है जो मुझे लगता है। क्या आपको अपना बैक-एंड लिखना चाहिए क्योंकि एपीआई ने मुझे यह सोचकर भ्रमित किया था कि एक ही वेबसर्विस होना चाहिए जो सामान करने के लिए सब कुछ (mvc ऐप, डेस्कटॉप ऐप, मोबाइल ऐप) कॉल करता है।

मैं जो निष्कर्ष पर आया हूं वह यह है कि आपको वास्तव में क्या करना चाहिए, यह सुनिश्चित करें कि आपके व्यापार तर्क परत को सही ढंग से डिकोड किया गया है। मेरे कोड को देखते हुए, मैं पहले से ही ऐसा करता हूं - नियंत्रक GetUser()एक प्रबंधक को कॉल करेगा , फिर इसे व्यू व्यू के साथ रेंडर करने के लिए एक व्यू मॉडल बनाएं। तो सच में, व्यापार तर्क परत है एक API। यदि आप इसे डेस्कटॉप ऐप से कॉल करना चाहते हैं, तो आपको इसे कॉल करने की सुविधा के लिए WCF सेवा जैसा कुछ लिखना होगा। यहां तक कि सिर्फ एक WCF विधि कहा जाता GetUser()है जिसमें कोड return MyBusinessLayer.GetUser()पर्याप्त होगा। तो एपीआई व्यावसायिक तर्क है, और डब्ल्यूसीएफ / वेब एप आदि बाहरी कोड को कॉल करने के लिए कोड के केवल शीर्षक हैं।

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

उम्मीद है कि यह व्याख्या सही है। सभी चर्चा / टिप्पणियों के लिए धन्यवाद जो इसे उत्पन्न किया है।

mvc asp.net-mvc api-design

— NibblyPig
स्रोत

25

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

— लॉरेंट एस।

12

@ एसएलसी: जब आप एपीआई कहते हैं, तो क्या आपका मतलब वेब सेवा एपीआई जैसे सोप या रीस्ट इंटरफेस है? क्योंकि आपको बैक-एंड एपीआई बनाना चाहिए, लेकिन आपको इसे वेब सेवा नहीं बनाना चाहिए।

— जैक्सबी

7

@IanNewson "एक मोबाइल ऐप, उदाहरण के लिए, उनके पास कम सुविधाएँ हैं।" मैंने कभी भी एक ठोस कारण नहीं सुना है कि मोबाइल ऐप्स दूसरे दर्जे के नागरिक क्यों होने चाहिए ... (फिर भी हर कोई इसे इस तरह से करता है)

— माइकल

3

@IanNewson शायद यह मेरे बस की बात है ... लेकिन मैं हमेशा खुद को हैमस्ट्रिंग पाता हूं कि मैं मोबाइल पर कुछ ऐसा काम या अन्य नहीं कर पा रहा हूं, जहां मैं मोबाइल पर बहुत कम काम करता हूं

— माइकल

11

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

— corsiKa

282

हाँ तुम्हें करना चाहिए।

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

एक क्षेत्र जहां यह इस समय लोकप्रिय है, वह माइक्रोसॉर्विस में है । जहां बैकएंड को कई छोटी (या बड़ी) सेवाओं में विभाजित किया जाता है जो प्रत्येक एक एपीआई प्रदान करते हैं जो क्लाइंट सिस्टम खपत करता है। यदि आप अपने आवेदन में डेटा के कई 3 पार्टी स्रोतों का उपयोग करने की कल्पना करते हैं, तो आपको लगता है कि आप पहले से ही ऐसा कर रहे हैं।

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

संपादित करें: ठीक है, मैं आपकी समस्या देखता हूं। आप एपीआई को एक दूरस्थ पुस्तकालय के रूप में सोचते हैं। यह। डेटा प्रदान करने वाली सेवा के रूप में सेवा के बारे में अधिक सोचें। आप डेटा प्राप्त करने के लिए सेवा को कॉल करते हैं और फिर उस डेटा पर स्थानीय रूप से संचालन करते हैं। यह निर्धारित करने के लिए कि क्या कोई उपयोगकर्ता लॉग ऑन है, आपको कॉल करेगा " GetUser" और फिर 'logged on'उदाहरण के लिए मूल्य देखें। ( YMMV उस उदाहरण के साथ, निश्चित रूप से)।

थोक उपयोगकर्ता निर्माण के लिए आपका उदाहरण सिर्फ बहाना बना रहा है - यहां कोई अंतर नहीं है, जो कुछ भी आप एक अखंड प्रणाली में कर सकते थे वह अभी भी एक सेवा वास्तुकला में किया जा सकता है (जैसे कि आपने उपयोगकर्ताओं की एक सरणी को बल्क-क्रिएट किया होगा, या बनाने के लिए एक एकल। आप अभी भी सेवाओं के साथ बिल्कुल वैसा ही कर सकते हैं)।

एमवीसी पहले से ही अलग-थलग सेवाओं की अवधारणा पर आधारित है, केवल एमवीसी ढांचे उन्हें एक ही परियोजना में बांधते हैं। इसका मतलब यह नहीं है कि आप बंधे हुए सहायकों को छोड़कर कुछ भी खो देते हैं जो आपका ढांचा आपको दे रहा है। एक अलग ढांचे का उपयोग करें और आपको विभिन्न सहायकों का उपयोग करना होगा। या, इस मामले में, अपना खुद का रोल करना (या उन्हें सीधे पुस्तकालय का उपयोग करके जोड़ना)।

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

सुरक्षा को लागू करने वाले अतिरिक्त काम जैसी चीजें एक अच्छी बात है। वर्तमान में, यदि आप अपनी वेबसाइट में सभी कोड को बंडल करते हैं, यदि कोई हैकर इसका उपयोग करता है, तो वे भी हर चीज तक पहुंच प्राप्त करते हैं, जिसमें डीबी शामिल है। यदि आप इसे एपीआई में विभाजित करते हैं, तो हैकर आपके कोड के साथ बहुत कम कर सकता है जब तक कि वे एपीआई परत को भी हैक न करें - जो उनके लिए अविश्वसनीय रूप से कठिन होगा (कभी सोचा कि हमलावर सभी वेबसाइट के उपयोगकर्ताओं या सीसी विवरणों की विशाल सूची कैसे प्राप्त करते हैं? उन्होंने OS या वेब सर्वर को हैक किया और इसका DB से सीधा संबंध था जहां वे select * from usersआसानी से " " चला सकते थे ।

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

2 संपादित करें: विषय पर कुछ लिंक (ओपी के लिए):

ध्यान दें कि जब किसी वेबसाइट के संदर्भ में इन के बारे में बात की जाती है, तो वेब सर्वर को प्रस्तुति परत माना जाना चाहिए, क्योंकि यह क्लाइंट है जो अन्य स्तरों को कॉल करता है, और यह भी क्योंकि यह यूआई दृश्यों का निर्माण करता है जो रेंडरिंग के लिए ब्राउज़र को भेजे जाते हैं। यह एक बड़ा विषय है, और आपके एप्लिकेशन को डिज़ाइन करने के कई तरीके हैं - डेटा-केंद्रित या डोमेन-केंद्रित (मैं आमतौर पर डोमेन केंद्रित को 'शुद्ध' मानता हूं, लेकिन YMMV ), लेकिन यह सब बीच में एक लॉजिक टियर को पूरा करने के लिए नीचे आता है। आपके ग्राहक और आपके डी.बी. यदि आप मध्य, एपीआई, स्तरीय को अपने मॉडल के समतुल्य मानते हैं तो यह MVC की तरह एक छोटा सा है, केवल मॉडल DB के लिए एक साधारण आवरण नहीं है, यह अधिक समृद्ध है और यह बहुत अधिक कर सकता है (जैसे 2 डेटा स्रोतों से कुल डेटा, पोस्ट एपीआई को फिट करने के लिए डेटा को बढ़ाएं, डेटा को कैश करें, आदि):

— gbjbaanb
स्रोत

2

क्या यह एक वास्तुकला अंतरिक्ष यात्री के दृष्टिकोण से हाँ है? मैं आपके 2 और 3 पैराग्राफ को सेवा के दृष्टिकोण से समझ सकता हूं, लेकिन हम GetUser, CreateUser, IsUserLoggedIn और सैकड़ों छोटे कार्यों के बारे में बात कर रहे हैं जो पहले एपीआई कॉल में परिवर्तित किए जा रहे कोड की एकल लाइनें थीं।

— निब्लीपिग

12

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

— gbjbaanb

5

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

— किक

2

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

— रीड

2

इससे वेबबेस से एक ही लॉजिक का उपयोग करना भी आसान हो जाता है। उन चीजों में से एक जो हमारी टीमों को हमेशा लगता है कि हमें कभी नहीं करना होगा ... यह इकाई परीक्षण को आसान बनाता है, साथ ही साथ।

— ps2goat

87

आप संभवतः API बनाने से बच नहीं सकते । यहां तक कि अगर आप "सिर्फ एक वेबसाइट" का निर्माण करते हैं, तो भी इसे किसी भी तरह अपने बैकएंड से अपना डेटा प्राप्त करना होगा। हालाँकि आप ऐसा करने का निर्णय लेते हैं, यह आपका वास्तविक एपीआई है।

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

फिर भी, यह कुछ चिंताओं के साथ लाता है, जैसा कि आप बताते हैं। उन्हें संबोधित करने के लिए:

यह एक एपीआई से अपने बैकएंड को चलाने के लिए बहुत सार है। आप इसे बहुत लचीला बनाने की कोशिश कर रहे हैं जो इसे एक असहनीय गड़बड़ कर देगा।

यह इस बात पर निर्भर करता है कि आप इसे कैसे करते हैं। जैसा कि जॉर्ज पोलिया अपने उत्कृष्ट पाठ में बताते हैं कि इसे कैसे हल किया जाए , अक्सर "अधिक सामान्य समस्या को हल करना आसान हो सकता है"। इसे आविष्कारक का विरोधाभास कहा जाता है । प्रोग्रामिंग के मामले में, यह अक्सर चिंताओं को अलग करने के माध्यम से काम करता है: आपके बैकएंड को अब उस डेटा के प्रारूप से चिंतित नहीं होना पड़ता है जो इसे डालता है और बाहर निकालता है, और इसलिए इसका कोड बहुत सरल हो सकता है। आपके डेटा पार्सर और रेंडरर्स को अब इस बात से चिंतित नहीं होना पड़ता है कि उनके द्वारा बनाए गए डेटा का क्या होगा, इसलिए वे भी सरल हो सकते हैं। यह सब कोड को अधिक प्रबंधनीय विखंडू में तोड़कर काम करता है।

MVC में निर्मित सभी चीजें बेकार लगती हैं, जैसे भूमिकाएं और प्रमाणीकरण। उदाहरण के लिए, [अधिकृत] विशेषताएँ और सुरक्षा; आपको अपना रोल खुद करना होगा।

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

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

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

आपके सभी एपीआई कॉल के लिए सुरक्षा संबंधी जानकारी संलग्न करनी होगी, और आपको एक टोकन सिस्टम और व्हाट्सएप विकसित करना होगा।

हाँ। इसे इस तरह का होना चाहिए है।

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

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

जब API की बात आती है तो आप इंटरफेस और अमूर्त वर्गों जैसे सभी प्रकार के उपकरण खो देते हैं। WCF जैसे स्टफ को इंटरफेस के लिए बहुत ही कठिन समर्थन है।

इसके विपरीत, जब आप API का उपयोग कर रहे होते हैं , तो इंटरफेस बहुत अधिक महत्वपूर्ण हो जाता है, कम नहीं । वे अभ्यावेदन में आप उन्हें प्रस्तुत करते हैं। आजकल अधिकांश लोग इसके लिए JSON -based प्रारूप निर्दिष्ट करते हैं , लेकिन जब तक आप इसे अच्छी तरह से निर्दिष्ट करते हैं, तब तक आप अपनी इच्छानुसार किसी भी प्रारूप का उपयोग कर सकते हैं। आप बैकएंड पर इस प्रारूप में अपनी कॉल के आउटपुट को प्रस्तुत करते हैं, और जो कुछ भी आप चाहते हैं, उसे उसी सीमा तक पार्स कर सकते हैं (संभवतः इसी तरह की वस्तु)। ओवरहेड छोटा है, और लचीलेपन में लाभ बहुत बड़ा है।

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

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

YAGNI । जब तक आप विशेष रूप से दो पहचान वाले कामकाजी एप्लिकेशन, एक वेब और एक विंडोज एप्लिकेशन को उदाहरण के लिए लिखने की योजना नहीं बना रहे हैं, यह अतिरिक्त विकास कार्य की एक बड़ी मात्रा है।

नहीं, YANI (आप पहले ही इसकी आवश्यकता है)। मैंने ऊपर के रूप में रेखांकित किया। एकमात्र सवाल यह है कि इसमें कितना डिजाइन काम करता है।

जब आप एंड-टू-एंड के माध्यम से कदम नहीं रख सकते हैं तो डिबगिंग बहुत कठिन है।

आप एंड-टू-एंड के माध्यम से कदम क्यों नहीं उठा पाएंगे?

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

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

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

कुछ मायनों में, यह हार्डवेयर पक्ष पर RISC आर्किटेक्चर के विपरीत नहीं है । RISC और CISC (इसके पूर्ववर्ती) के बीच एक महत्वपूर्ण अंतर यह है कि CISC आर्किटेक्चर में कई निर्देश शामिल होते हैं जो सीधे मेमोरी पर काम करते हैं, जबकि RISC आर्किटेक्चर ज्यादातर रजिस्टरों में काम करते हैं: विशुद्ध रूप से RCC आर्किटेक्चर में, मेमोरी पर एकमात्र ऑपरेशन होता है। लोड (एक रजिस्टर में स्मृति से कुछ कॉपी करें) और स्टोर (एक रजिस्टर से एक मूल्य ले और स्मृति में डाल दिया)।

आपको लगता है कि इसका मतलब होगा कि मेमोरी से रजिस्टरों से कई और ट्रिप लेना, जो मशीन को धीमा कर देगा। लेकिन व्यवहार में, विपरीत अक्सर होता है: प्रोसेसर (क्लाइंट) मेमोरी (सर्वर) की यात्राओं के बीच अधिक काम करता है , और यह वह जगह है जहां से स्पीडअप आता है।

लंबी कहानी छोटी: आपका सहयोगी सही है। जाने का यह रास्ता है। एक छोटे से सामने के काम के बदले में, यह नाटकीय रूप से आपकी वेबसाइट के लिए कोड को सरल करेगा और अन्य वेबसाइटों और एप्लिकेशन के साथ बेहतर एकीकरण को सक्षम करेगा। यह मूल्य देने लायक है।

आगे की पढाई:

अन्य एपीआई डिजाइन - संसाधन मॉडलिंग

— स्पूनिएस्ट
स्रोत

7

यहां तक कि इनमें एक प्रकार का वास्तविक एपीआई भी होता है। वे कई अन्य डेवलपर्स को डरावनी बनाने की प्रवृत्ति रखते हैं, लेकिन वे सभी समान एपीआई हैं; बस बहुत अच्छी तरह से डिजाइन वाले नहीं हैं।

— द स्पूनिएस्ट

7

यह वास्तव में गरीब एपीआई के लिए बनाता है: इतना गरीब है कि बहुत से लोग इसे एपीआई के रूप में बिल्कुल भी नहीं सोचते हैं। लेकिन यह अभी भी इस तरह से परिभाषित करता है कि फ्रंटएंड बैकएंड के साथ बातचीत करता है, हालांकि इस तरह से क्रूड हो सकता है। यह एक एपीआई के रूप में सोचकर घर को अच्छी तरह से करने के महत्व को चलाने में मदद करता है।

— स्पूनिएस्ट

1

मुझे लगता है कि लिनुस ने गिट बनाया क्योंकि लिनक्स समुदाय ने वाणिज्यिक बिटकॉइन डीवीसीएस के उपयोग के खिलाफ विद्रोह किया था जो कि कर्नेल के लिए उपयोग किया गया था।

— gbjbaanb

2

आपका पहला वाक्य मेरी सारी उलझनें दूर कर देता है। मैंने एपीआई शब्द को एक वेब सेवा से जोड़ा है और यही मुख्य कारण है कि मैं इतना भ्रमित था।

— निब्लीपिग

4

@IanNewson: कोड के साथ इंटरफेस करने का एक तरीका है, इसे http कहा जाता है। इसकी बहुत सारी अप्रासंगिक आवश्यकताएं हो सकती हैं और बहुत अधिक अप्रासंगिक डेटा वापस मिल सकता है, लेकिन यही वह है जो इसे एक आकर्षक एपीआई बनाता है।

— जोमेरो

63

मुझे पता है कि माइक्रोसेर्वर अभी सभी गुस्से में हैं, लेकिन वे हमेशा इसके लायक नहीं हैं। हां, शिथिल युग्मित कोड ही लक्ष्य है। लेकिन यह अधिक दर्दनाक विकास चक्र की कीमत पर नहीं आना चाहिए।

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

Microsoft इस अवधारणा को बढ़ावा दे रहा है, जिसे वे पोर्टेबल क्लास लाइब्रेरी कहते हैं ।

— fotijr
स्रोत

13

मुझे एक परियोजना को बनाए रखना है जहां तर्क को यूआई परत में रखा गया था, उसी साझा डेटा संरचनाओं को कॉल करना। मुझे इसकी वजह से एक बग को तीस बार ठीक करना पड़ा है ("अगर हमें फिर से उसी तर्क का उपयोग करने की आवश्यकता है तो हम कॉपी और पेस्ट करेंगे! एपीआई की आवश्यकता नहीं है")। अगर वहाँ एक तर्क परत (अब वहाँ है) यह सिर्फ एक तय के साथ पर्याप्त होता।

— SJuan76

1

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

— ग्रेग बरगार्ड

34

नहीं, तुम नहीं करना चाहिए । यदि आपके पास वैकल्पिक फ्रंटएंड (जैसे मोबाइल या डेस्कटॉप ऐप या अलग वेब एप्लिकेशन) बनाने की तत्काल योजना नहीं है, जो एक ही बैकएंड तक पहुंचते हैं, तो आपको एक वेब सेवा परत पेश नहीं करनी चाहिए। YAGNI ।

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

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

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

— JacquesB
स्रोत

8

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

— लॉरेंट एस।

9

@ बर्टड्यूड: भविष्य के लिए "फ्यूचर-प्रूफिंग" की आवश्यकता के लिए अनावश्यक जटिलता का परिचय, जो नहीं आएगी, केवल संसाधनों को बर्बाद कर रही है।

— जैक्सबी

6

@ कर्ता को जोड़ने से निश्चित रूप से अधिक समय लगता है। कोई विचार नहीं कि आप कैसे सोचते हैं कि आप अन्यथा दावा कर सकते हैं।

— इयान न्यूजन

13

"आपको एक वेब सेवा परत का परिचय नहीं देना चाहिए" API! = वेब सेवा। यदि आपके पास एक एपीआई के पीछे अपना व्यावसायिक तर्क है, तो आप उस एपीआई को किसी बिंदु पर एक वेब सेवा के रूप में उजागर कर सकते हैं । यह एक सामने की आवश्यकता नहीं है, यद्यपि।

— सेलोस

2

@JacquesB: ... तो अगर आप सुनिश्चित नहीं हैं कि आपको इसकी ज़रूरत है, तो आप वास्तव में सुविधाओं का विकास नहीं करेंगे। यही मैं YAGNI से समझता हूं। फिर भी वास्तुकला एक विशेषता नहीं है और बुरे वास्तुशिल्प विकल्प (और शायद सबसे अधिक) एक दुखी विफलता का कारण बन सकते हैं। एक बार फिर मुझे लगता है कि यह चर्चा और भी घटित हो सकती है, जो कभी-कभी बजट, समय-समय पर बाजार, पुनर्संरचना या ज्ञान की कमी के कारण नहीं होती ... मुझे लगता है कि हम इस पर असहमत होने के लिए पूरी तरह सहमत हो सकते हैं, हालांकि मैं आपकी बात समझता हूं क्योंकि मैं अक्सर अपने साथ ^ _ ^

— लॉरेंट एस।

29

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

इस पर एक आंकड़ा लगाने के लिए, मैं इस दृष्टिकोण के कारण लागत से 20% अधिक ऊपर उल्लिखित परियोजना का अनुमान लगाऊंगा। आप यह नहीं बताते हैं कि आप किस प्रकार के प्रोजेक्ट पर काम कर रहे हैं, आप किस तरह की कंपनी के लिए काम कर रहे हैं, लेकिन यदि आप अपने उत्पाद का निर्माण शुरू कर रहे हैं, तो अतिरिक्त लागत शिपिंग के बीच अंतर हो सकती है जो आपके उत्पाद को बनाते हैं। सफलता।

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

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

— इयान न्यूज़न
स्रोत

22

यह आवेदन के प्रकार और आपके द्वारा बाज़ार के प्रकार पर निर्भर करता है।

इस तरह जाने के व्यापार-लाभ और लाभ हैं। यह एक स्पष्ट जवाब नहीं है कि एक तरीका दूसरे से बेहतर है।

मैं व्यक्तिगत अनुभव से बात करूंगा। मैं वह था जिसने 2007 में वापस इस दिशा में काम करने वाले कोडबेस को लेने का फैसला किया था। यह कोडबेस अब कोड की एक लाख लाइनों के क्रम में है, जिनमें से आधे सर्वर कोड वेब सेवा की भारी मात्रा के पीछे छिपे हुए हैं। एपीआई का, अन्य आधा ग्राहकों का एक फ्लोटिला है, डेस्कटॉप देशी, डेस्कटॉप वेब, मोबाइल, बैक-एंड इंटीग्रेशन, आदि ... यह निर्णय इसके डाउनसाइड के बिना नहीं था, लेकिन 20/20 के साथ मैं कह सकता हूं कि मैं इसे फिर से करूंगा। । मुझे कुछ ट्रेड-ऑफ में शामिल होने का संकेत दें।

लाभ

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

व्यापार नापसंद

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

लाल कान की बालियां

आपने इनमें से एक समूह का उल्लेख किया है। वे वास्तव में व्यवहार में मायने नहीं रखते।

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

संक्षेप में

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

— जोएरी सेब्रेट्स
स्रोत

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

— आआआआआआ आआआआआ

3

तीन मुख्य गलतियाँ थीं: (1) प्राथमिक ui की जरूरतों को पूरा करने के लिए, (2) सत्रों का उपयोग करते हुए कई अनुरोधों के बीच राज्य का निर्माण (हम धीरे-धीरे सत्रहीन हो रहे हैं), और (3) केवल उत्पन्न के उपयोग का समर्थन कर रहे हैं पहचानकर्ता के रूप में db आईडी जहां एक उपयोगकर्ता-विन्यास कोड अक्सर एक बेहतर पहचानकर्ता होता है (बाहरी प्रणालियों के साथ एकीकरण के लिए आमतौर पर वे हमारे सिस्टम में पहचानकर्ताओं को बाद के एपि के उपयोग के लिए, इसके विपरीत में अपलोड करना चाहते हैं)। उन तीनों ने कमजोर प्रलेखन और अनपेक्षित त्रुटि संदेशों के साथ एपीआई को सहायता के बिना उपयोग करना असंभव बना दिया।

— जोएरी सेबर्चेस

10

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

SOA के कुछ महत्वपूर्ण लाभ हैं, जिन्हें मैं सम्‍मिलित करने का प्रयास करूंगा:

अनुमापकता

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

आपके API को लगातार बने रहना है, लेकिन यदि आप अपनी मौजूदा तकनीक को आगे बढ़ाते हैं, तो बिना स्टैक को तोड़े तेजी से प्रौद्योगिकी के लिए स्वैप किया जा सकता है। आप इसे उदाहरण के लिए गो में रीमेक कर सकते हैं। आप इसे टुकड़ों में पुनर्निर्माण कर सकते हैं और सर्वर पर लोड फैला सकते हैं। जब तक इंटरफ़ेस बना रहता है तब तक वही तकनीक अमूर्त होती है।

testability

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

एक एपीआई इस मुद्दे को दरकिनार करता है। प्रत्येक एपीआई कॉल एक संसाधन को खींचता है और इसे कार्य करता है। साफ और परीक्षण योग्य।

चिंताओं को अलग करने की गारंटी

आपका फ्रंट एंड और बैक एंड पूरी तरह से तलाकशुदा है। आप किसी दूसरे डेवलपर या डिजाइनर को फ्रंट एंड दे सकते हैं। यह एमवीसी को दूसरे स्तर पर ले जाया गया है। मुझे यकीन है कि आप एमवीसी को छोड़ना नहीं चाहेंगे। SOA MVC है लेकिन अधिक-तो।

downsides

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

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

— superluminary
स्रोत

यह अब तक का सबसे स्पष्ट उत्तर है।

— टोनी एननिस

7

यहाँ अच्छे जवाबों का एक अच्छा सौदा है इसलिए मैं सिर्फ अपने कार्यान्वयन का अनुभव जोड़ूंगा।

मैं यह कैसे काम करता हूं:

एक डेटाबेस एक्सेस लेयर बनाएं जो सभी / केवल DB इंटरैक्शन को हैंडल करता है (आमतौर पर मैन्युअल SQL का उपयोग गति और नियंत्रण के लिए किया जाता है, कोई ORM नहीं) । सम्मिलित करें, अद्यतन करें, हटाएं, चुनें ...
एक interface( बनाएं virtual class) जो मेरे द्वारा आवश्यक एपीआई फ़ंक्शंस को उजागर / लागू करता है। लागू होने पर, वे परिणाम प्राप्त करने के लिए अत्यधिक विशिष्ट डीबीएएल कार्यों का उपयोग करेंगे। यह कंपाइलर स्तर पर एपीआई को लागू करने में भी मेरी मदद करता है इसलिए मैं यह सुनिश्चित करता हूं कि सर्वर + एपीआई कार्यान्वयन में निर्मित सभी फ़ंक्शन हैं।
दूसरा लेयर बनाएँ जो इंटरफ़ेस को लागू करता है (यह वास्तविक एपीआई है) और सुरक्षा प्रतिबंध लागू करता है। आप यहां बाहरी एपीआई के साथ भी बातचीत करते हैं।
वेबसाइट दूरस्थ पहुंच-योग्य API (जैसे SOAP, JSON) पर जाए बिना सीधे (प्रदर्शन के लिए) दूसरी परत का उपयोग करेगी ।
एक स्टैंडअलोन सर्वर का निर्माण होता है जो इंटरफ़ेस को लागू करता है और बाहरी डेस्कटॉप / मोबाइल क्लाइंट (गैर-वेबसाइट एक्सेस) के लिए वास्तविक रिमोट-एक्सेस एपीआई के रूप में दूसरी परत को उजागर करता है । यह सब करता है अनुरोधों को डीकोड करना और प्रतिक्रियाओं को सांकेतिक शब्दों में बदलना और ग्राहकों को काटना / प्रबंधित करना है। यह अन्य जुड़े साथियों द्वारा उत्पन्न घटनाओं के बड़े पैमाने पर सूचित ग्राहकों को कार्यक्षमता का समर्थन करता है (कार्यक्षमता जो एक वेबसाइट को आमतौर पर आवश्यकता नहीं होती है) ।

तो, तकनीकी रूप से, एपीआई दूसरा परत है। आप इसे सीधे वेबसाइट के साथ उपयोग करते हैं और इसे सर्वर के माध्यम से दूरस्थ क्लाइंट के लिए उजागर करते हैं। कोड का पुन: उपयोग किया जाता है और कोड का कोई पुन: प्रयोज्य हिस्सा कभी भी इनलाइन नहीं होता है। (इस नियम से जीना और मरना और सब कुछ बहुत बढ़िया है) स्थिरता, परीक्षण ... सब कुछ के साथ मदद करता है।

आप वेबसाइट को कभी भी डेस्कटॉप / मोबाइल एपीआई सर्वर से कनेक्ट नहीं करते हैं (जब तक कि आपकी साइट AJAX नहीं है और JSON पर चलती है) । लेकिन अगर साइट मार्कअप में डायनामिक कंटेंट प्रस्तुत करती है, तो इंटरमीडिएट एपीआई के माध्यम से जाने से आपका प्रदर्शन प्रभावित होगा। वेबसाइट को तेज़ करने की आवश्यकता है! रिमोट क्लाइंट एक्सेस थोड़ा और अधिक धीमा हो सकता है।

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

— CodeAngry
स्रोत

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

— निब्लीपिग

6

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

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

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

उदाहरण

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

एपीआई कॉल की संख्या इसके लिए एक सभ्य एपीआई की आवश्यकता होगी, शायद 1 होगा। हां, यह अनम्य है, लेकिन आप इसे लचीला क्यों चाहते हैं?

— पीटर
स्रोत

4

उन्होंने कहा कि हमारा कोड बहुत अधिक युग्मित था। उदाहरण के लिए, यदि हम एक डेस्कटॉप एप्लिकेशन भी चाहते हैं, तो हम अपने मौजूदा कोड का उपयोग नहीं कर पाएंगे।

आप अच्छी तरह से करते हैं? यदि नहीं, तो यह एक बहुत ही अप्रासंगिक कथन है।

मैं कहता हूं, यदि आप 2015 में एक नया एप्लिकेशन बनाने जा रहे थे , तो गंभीरता से एक उपयोगकर्ता इंटरफ़ेस के साथ कुछ देखें जिसमें एक एपीआई शामिल हो और न कि सर्वर से उत्पन्न HTML पृष्ठ। स्पष्ट लागत हैं लेकिन स्पष्ट लाभ भी हैं।

लेकिन अगर आपके पास एक मौजूदा साइट है जिसमें बिना किसी ठोस योजना के कई अलग-अलग इंटरफेस हैं (जहां तक मैं बता सकता हूं), तो उनकी टिप्पणियां सिर्फ अप्रासंगिक हैं।

— RemcoGerlich
स्रोत

4

लघु संस्करण: आपका नियंत्रक प्रभावी रूप से एक एपीआई है चाहे कोई भी हो; हालांकि ASP.NET अस्पष्ट हो सकता है।

लंबा संस्करण:

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

/sign_in
/sign_out
/beer
/beer/{beer_name}
/order
/order/{order_number}

एक सामान्य वेब-ऐप में, कुछ सहायक मार्ग जैसे होने की संभावना है:

/beer/new
/beer/{beer_name}/edit
/beer/{beer_name}/delete
/order/new
/order/{order_number}/edit
/order/{order_number}/delete

वेब API में वे आवश्यक नहीं हैं, क्योंकि वे HTTP विधि से अनुमानित हैं।

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

कुछ खुदाई करने के बाद, मैंने निर्धारित किया है कि आपके लिए एएसपी.नेट के किस संस्करण के आधार पर यह आपके लिए चीजों की स्थिति हो सकती है। पुराने MVC 5 और कन्वेंशन और इंटरफेस की कमी से पहले दो कार्यान्वयन को एकजुट करने के लिए। पुराने संस्करणों में, वेब ऐप रिटर्न एक दृश्य को पॉप्युलेट करता है जबकि एपीआई एक HttpResponse देता है। हालाँकि, किसी भी स्थिति में, वे ठीक उसी प्रतिक्रिया को शब्दार्थ से उत्पन्न कर रहे हैं ।

यदि आप MVC 6 का उपयोग कर रहे हैं, तो आप दोनों को एक एकीकृत नियंत्रक वर्ग में मिलता है जो कि यह रिटर्न के बारे में स्मार्ट हो सकता है। मुझे इस मॉडल के लिए कोई अच्छा एएसपी उदाहरण कोड नहीं मिला है, लेकिन मुझे उसी पैटर्न के साथ कुछ रेल कोड मिला है। प्रवासी परियोजना से "पसंद" के लिए इस नियंत्रक पर विचार करें । प्रत्येक नियंत्रक विधि एक "संसाधन सम्मेलन" द्वारा परिभाषित मार्गों है यहाँ एक API में LCRUD उस राशि।

यदि आप कार्यान्वयन पढ़ते हैं, हालांकि, प्रत्येक संभवतः HTML, मोबाइल HTML, या JSON पर प्रतिक्रिया दे सकता है। यह, विचारों को खोजने के लिए एक सम्मेलन के साथ संयुक्त रूप से, वेब ऐप और वेब एपीआई को पूरी तरह से एकीकृत करता है। आप यह भी ध्यान देंगे कि सभी विधियाँ वास्तव में प्रत्येक प्रतिक्रिया प्रदान नहीं करती हैं (जो समझ में आता है, क्योंकि UI को उन तरीकों की आवश्यकता हो सकती है जो एपीआई नहीं करेंगे, और इसके विपरीत)।

यह एक प्रतिबाधा बेमेल है क्योंकि ASP.NET इस तरह के सभी का देर से पता लगाता है जबकि रेल ने कुछ समय के लिए समरूपता को अपनाया है और यह बहुत स्पष्ट है।

अटकलें:

आपका सहकर्मी शायद सही और गलत दोनों है, जिसके आधार पर आप जिस एएसपी संस्करण का उपयोग कर रहे हैं। पुराने एमवीसी संस्करण के तहत, एपीआई और ऐप के बीच के अंतर ने शायद एपीआई को बनाने के लिए "सबसे अच्छा अभ्यास" किया, क्योंकि ASP.NET का मॉडल वास्तव में अच्छे कोड के पुन: उपयोग के लिए अनुमति नहीं देता था।

नए के साथ, यह एकीकृत कोड का उपयोग करने के लिए अधिक समझ में आता है क्योंकि एकीकृत नियंत्रक आधार वर्ग के साथ कोड का फिर से उपयोग करना आसान बना दिया गया है।

हालाँकि, किसी भी स्थिति में, नियंत्रक प्रभावी रूप से एपीआई है।

— जेसन
स्रोत

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

— जेसन

मर्जर का अधिक जवाब, वे इस बारे में अन्य लोगों को क्या महसूस करते हैं, इसकी अच्छी तरह से सराहना पाने में मदद करते हैं।

— निब्लीपिग जूल

2

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

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

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

— Stilgar
स्रोत

2

तीसरे पक्ष इसका उपयोग करेंगे? हाँ, आपको करना चाहिए ।

आप इसे फिर से उपयोग नहीं करने की योजना बनाते हैं? हाँ तुम्हें करना चाहिए। डॉक्यूमेंटेड - या डॉक्युमेंटेबल - या प्रयोग करने योग्य-थर्ड-पार्टी एपीआई वाले आपको
आपकी तीसरी पार्टी होगी, जो आपको ठोस पुन: प्रयोज्यता और प्रतिरूपकता प्रदान करेगी।

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

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

— ZJR
स्रोत

1

यहां अच्छे जवाब हैं। मैं इसे आंशिक उत्तर के रूप में पोस्ट करता हूं; यह शायद एक टिप्पणी के रूप में बेहतर होगा। हालाँकि एक ही टिप्पणी को कई पोस्ट पर चिपकाना अच्छा नहीं है।

कोई यह दावा नहीं कर सकता कि YAGNI एक एपीआई नहीं बनाने का एक कारण है।

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

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

— टोनी एननिस
स्रोत