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

Cloud Series के पहले के कुछ ब्लॉग इस प्रकार हैं:

Async संचार 101
लोड संतुलन 101 कैशिंग 101 डेटाबेस 101

एक एपीआई क्या है?

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

वास्तविक संचालन के आधार पर, एपीआई विभिन्न प्रकार के हो सकते हैं- GET, POST, PUT, PATCH, DELETE आदि । दस्तावेज़ जो अनुरोध बॉडी/हेडर, r esponse बॉडी/हेडर के हिस्से के रूप में भेजा गया है, के विनिर्देश को शामिल करता है । एपीआई विनिर्देश।

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

आरईएसटी एपीआई के प्रकार

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

• GET - एक निर्दिष्ट URI स्थान पर एक संसाधन प्राप्त करता है। सामान्य प्रतिक्रिया कोड 200 ( सामग्री मौजूद है), 204 (कोई सामग्री नहीं), या 404 (नहीं मिला) हैं।
• पोस्ट - निर्दिष्ट यूआरआई स्थान पर संसाधन बनाता है। सामान्य प्रतिक्रिया कोड 201 (सामग्री निर्मित) या 400 ( खराब अनुरोध) हैं।
• PUT - निर्दिष्ट URI स्थान पर संसाधन बनाता या बदलता है। सामान्य प्रतिक्रिया कोड 201 (सामग्री निर्मित), 204 (कोई सामग्री नहीं) या 409 (संघर्ष) हैं
• PATCH - किसी निर्दिष्ट URL पर संसाधन को आंशिक रूप से अपडेट करता है। सामान्य प्रतिक्रिया कोड 201 (सामग्री निर्मित) या 400 (खराब अनुरोध) हैं।
• DELETE — निर्दिष्ट URL पर संसाधन को हटाता है। सामान्य प्रतिक्रिया कोड 204 (कोई सामग्री नहीं) या 404 (नहीं मिला) हैं

• स्तर 1.0 - आरईएसटी एप्लिकेशन आर्किटेक्चर के कम से कम अनुरूप , यह स्तर पूरे एप्लिकेशन के लिए केवल एक HTTP पोस्ट विधि को उजागर करता है
• स्तर 2.0 — स्तर 1.0 के विपरीत, यह स्तर विभिन्न संसाधनों के लिए कई HTTP पोस्ट यूआरआई को उजागर करता है।
• स्तर 3.0 — स्तर 2.0 की तुलना में अधिक परिपक्व, यह स्तर विभिन्न तरीकों जैसे GET, POST, PUT, PATCH आदि को उजागर करता है।
• स्तर 4.0 - सबसे परिपक्व और दुर्लभतम स्तर, यह स्तर हाइपरटेक्स्ट के माध्यम से आवेदन के विभिन्न राज्यों को उजागर करता है, जिसे HATEOAS भी कहा जाता है ।

• एपीआई एंडपॉइंट वास्तविक क्रियाओं की तुलना में संज्ञाओं पर आधारित होना चाहिए। उदाहरण - domain.com/orders/ , domain.com/create-orders/ से बेहतर है ।
• एपीआई से बचा जाना चाहिए जो केवल आंतरिक डेटाबेस संरचना को प्रतिबिंबित करता है। यदि डेटाबेस इंजन का अंतर्निहित स्कीमा बदलता है, तो एपीआई उसी से स्वतंत्र होना चाहिए।
• उन एपीआई से बचें जिनमें यूआरआई पदानुक्रम के तीन से अधिक स्तर हैं। उदा - domain.com/x1/x2/x3 से बचना चाहिए।
• छोटे संसाधनों को उजागर करने के लिए चैटी एप्लिकेशन यानी कई एपीआई कॉल से बचना चाहिए। यह वेब सर्वर पर समग्र भार को बढ़ाता है, इसके बजाय एपीआई को आदर्श रूप से बड़े संसाधनों को वापस करना चाहिए।
• पश्चगामी संगतता सुनिश्चित करने के लिए आरामदेह एपीआई को संस्करणबद्ध किया जाना चाहिए। उदाहरण- domain.com/v1/orders और domain.com/v2/orders।
• कोई एपीआई प्रतिक्रिया किसी भी एप्लिकेशन राज्यों को कवर नहीं करना चाहिए और एपीआई को व्यावसायिक प्रवाह में कॉल करने का सापेक्ष क्रम स्वतंत्र होना चाहिए।

एक नमूना जावा रेस्ट एप्लिकेशन के साथ खेलने के लिए जिसमें एक सेवा और मॉडल परत सक्षम है, निम्नलिखित रेपो का उपयोग किया जा सकता है।

सारांश

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

प्रतिक्रिया के लिए, कृपया amit[dot]894[at]gmail[dot]com पर एक संदेश भेजें या https://about.me/amit_raj पर किसी भी लिंक पर पहुंचें ।