RESTful APIs को समझना और उपयोग करना

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

API क्या है

एक पल के लिए यह जाने कि API क्या है, आइए हम बात करते हैं कि हम अपने जीवन में जानकारी कैसे पहुंचाते हैं।

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

दूसरी ओर, कंप्यूटर सॉफ्टवेयर यह काम APIs के माध्यम से पूरा करता है। आइए विकिपीडिया की परिभाषा से शुरू करें:

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

सॉफ्टवेयर A, API के माध्यम से सॉफ्टवेयर B को अनुरोध भेजता है, और सॉफ्टवेयर B अपने संसाधनों को क्वेरी करने के बाद API के माध्यम से A को प्रतिक्रिया देता है।

सॉफ्टवेयर A द्वारा सॉफ्टवेयर B को API के माध्यम से अनुरोध भेजना आपके बॉस को बताने जैसा है कि आपको बैटरी चाहिए, और सॉफ्टवेयर B द्वारा सॉफ्टवेयर A को डेटा वापस करना आपके बॉस द्वारा बैटरी ढूंढकर आपको देने जैसा है।

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

RESTful API क्या है

रॉय फील्डिंग ने अपने 2000 के पीएच.डी. शोध प्रबंध, "आर्किटेक्चरल स्टाइल्स और वेब-आधारित सॉफ्टवेयर आर्किटेक्चर डिजाइन" में REST (रिप्रेजेंटेशनल स्टेट ट्रांसफर) को परिभाषित किया, और REST आर्किटेक्चरल स्टाइल छह मार्गदर्शक बाधाओं को परिभाषित करता है। एक सिस्टम जो इन बाधाओं में से कुछ या सभी का पालन करता है, उसे आमतौर पर RESTful कहा जाता है।

(स्रोत: Seobility)

RESTful APIs की बाधाएं

RESTful API बेस्ट प्रैक्टिस

घटकों के बीच एकीकृत इंटरफेस पर जोर देना एक मुख्य विशेषता है जो REST आर्किटेक्चरल स्टाइल को अन्य वेब-आधारित शैलियों से अलग करती है, और इस विशेषता के आधार पर, यहां बेस्ट प्रैक्टिस को सॉर्ट किया गया है ताकि आप अपने API को बेहतर ढंग से डिजाइन कर सकें।

पाथ नाम में क्रियाओं से बचें

संसाधन हेरफेर व्यवहार को व्यक्त करने के लिए HTTP मेथड्स का उपयोग करें, बजाय व्यवहार क्रियाओं को पाथ में परिभाषित करने के।

// अच्छा
curl -X GET http://httpbin.org/orders

// बुरा
curl -X GET "http://httpbin.org/getOrders"

• GET का उपयोग करके निर्दिष्ट URI के लिए संसाधन जानकारी प्राप्त करें

// वर्तमान सिस्टम के सभी ऑर्डर जानकारी प्राप्त करने का प्रतिनिधित्व करता है
curl -X GET http://httpbin.org/orders

// ऑर्डर नंबर 1 के लिए ऑर्डर विवरण जानकारी प्राप्त करने का प्रतिनिधित्व करता है
curl -X GET http://httpbin.org/orders/1

• POST का उपयोग करके निर्दिष्ट URI से संसाधन बनाएं

 // नाम order के साथ एक संसाधन बनाने का प्रतिनिधित्व करता है
curl -X POST http://httpbin.org/orders \
  -d '{"name": "awesome", region: "A"}' \

• PUT का उपयोग करके निर्दिष्ट URI पर संसाधन बनाएं या पूरी तरह से बदलें

 // आईडी 1 वाले ऑर्डर के लिए डेटा प्रतिस्थापन का प्रतिनिधित्व करता है
curl -X PUT http://httpbin.org/orders/1 \
  -d '{"name": "new awesome", region: "B"}' \

• PATCH संसाधन का आंशिक अपडेट करता है

 // आईडी 1 वाले ऑर्डर के region फील्ड को बदलने का प्रतिनिधित्व करता है, जबकि बाकी डेटा को अपरिवर्तित रखता है
curl -X PATCH http://httpbin.org/orders/1 \
  -d '{region: "B"}' \

• DELETE का उपयोग करके निर्दिष्ट URI से संसाधन हटाएं

 // आईडी 1 वाले ऑर्डर को हटाने का प्रतिनिधित्व करता है
curl -X DELETE http://httpbin.org/orders/1

URIs में बहुवचन रूप का उपयोग करें

यदि आप किसी विशेष प्रकार के संसाधन तक पहुंचने के लिए एकवचन रूप का उपयोग करना चाहते हैं:

curl -X GET "http://httpbin.org/order"

एकवचन रूप का उपयोग करने से उपयोगकर्ता को यह भ्रम हो सकता है कि सिस्टम में केवल एक ऑर्डर है, लेकिन बहुवचन रूप का उपयोग करने से इसे समझना बहुत आसान हो जाता है।

curl -X GET "http://httpbin.org/orders"

HTTP स्टेटस कोड का अच्छा उपयोग करें

HTTP मानक स्टेटस कोड को परिभाषित करता है, जिन्हें निम्नलिखित श्रेणियों में वर्गीकृत किया जा सकता है:

मानक स्टेटस कोड का उपयोग करके, डेवलपर्स तुरंत समस्याओं की पहचान कर सकते हैं और विभिन्न प्रकार की त्रुटियों को खोजने में लगने वाले समय को कम कर सकते हैं।

वर्जन कंट्रोल

जैसे-जैसे बिजनेस आवश्यकताएं बदलती हैं, ऑनलाइन APIs को संभवतः तदनुसार समायोजित करना होगा। यदि हमारे APIs का उपयोग तीसरे पक्ष द्वारा किया जाता है, तो यह स्पष्ट रूप से असंभव है कि हर क्लाइंट को हमारे APIs के परिवर्तनों के अनुसार बदलने दिया जाए, इसलिए API वर्जन प्रबंधन की अवधारणा को पेश करने का समय आ गया है, जो ऐतिहासिक APIs के सामान्य उपयोग को सुनिश्चित कर सकता है और नई बिजनेस आवश्यकताओं को पूरा करने के लिए नए APIs को इटरेट कर सकता है।

वर्जन कंट्रोल के सामान्य साधन हैं:

• अनुरोधों में पाथ के माध्यम से वर्जन कंट्रोल

// v1 API का अनुरोध
curl  http://httpbin.org/v1/orders

// v2 API का अनुरोध
curl  http://httpbin.org/v2/orders

• क्वेरी पैरामीटर्स के माध्यम से वर्जन कंट्रोल

// v1 API का अनुरोध
curl  http://httpbin.org/orders?version=v1

// v2 API का अनुरोध
curl  http://httpbin.org/v2/orders?version=v2

• हेडर के माध्यम से वर्जन कंट्रोल

// v1 API का अनुरोध
curl  http://httpbin.org/orders -H "custom-version: v1"

// v2 API का अनुरोध
curl  http://httpbin.org/orders -H "custom-version: v2"

APISIX RESTful API को कैसे सशक्त बनाता है

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

लेयर्ड सिस्टम: बिजनेस लॉजिक और सुरक्षा लॉजिक को अलग करने का समर्थन

आप केवल बिजनेस लॉजिक के कार्यान्वयन पर ध्यान केंद्रित कर सकते हैं, इंटरफेस की सुरक्षा लॉजिक को APISIX ऑथेंटिकेशन क्लास प्लगइन्स, जैसे key-auth, पर छोड़ सकते हैं। APISIX बड़ी संख्या में ऑथेंटिकेशन प्लगइन्स का समर्थन करता है, आइए openid-connect को उदाहरण के रूप में लें, जैसा कि निम्नलिखित चित्र में दिखाया गया है:

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

लेयर्ड सिस्टम: मल्टी-लोड बैलेंसिंग प्रोटोकॉल समर्थन

APISIX, एक API गेटवे के रूप में, क्लाइंट और सर्वर साइड के बीच स्थापित किया जा सकता है ताकि विभिन्न लोड आवश्यकताओं को पूरा किया जा सके। आप यहां तक कि लोड-बैलेंसिंग लॉजिक को कस्टमाइज़ कर सकते हैं।

समर्थित लोड-बैलेंसिंग एल्गोरिदम हैं:

• roundrobin: वेट के साथ राउंड रॉबिन बैलेंसिंग।
• chash: कंसिस्टेंट हैश।
• ewma: न्यूनतम लेटेंसी वाले नोड को चुनें। अधिक जानकारी के लिए EWMA चार्ट देखें।
• least_conn: (active_conn + 1) / weight के सबसे कम मूल्य वाले नोड को चुनें। यहां, एक सक्रिय कनेक्शन एक कनेक्शन है जो अनुरोध द्वारा उपयोग किया जा रहा है और Nginx में अवधारणा के समान है।
• require("apisix.balancer.your_balancer") के माध्यम से लोड किया गया यूजर-डिफाइंड लोड बैलेंसर

यूनिफॉर्म इंटरफेस: ऐतिहासिक APIs को अधिक RESTful बनाएं

लंबे समय से मौजूद और RESTful API दिशानिर्देशों का अच्छी तरह से पालन नहीं करने वाले ऐतिहासिक APIs के लिए, आप APISIX के माध्यम से नए API को पुन: एनकैप्सुलेट कर सकते हैं ताकि विभिन्न बिजनेस परिदृश्यों को पूरा किया जा सके, बिना मूल API लॉजिक को बदले।

• proxy-rewrite का उपयोग करके क्लाइंट अनुरोधों को रीराइट करें

जैसा कि ऊपर बताया गया है, हमें अपने पाथ में क्रियाओं को नहीं रखना चाहिए।

उदाहरण के लिए, यदि ऐतिहासिक API में /getOrder इंटरफेस है, तो हम proxy-rewrite प्लगइन के माध्यम से API अनुरोध को ऐतिहासिक API पर प्रॉक्सी कर सकते हैं।

curl http://127.0.0.1:9080/apisix/admin/routes/1  -H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PUT -d '
{
    "methods": ["GET"],
    "uri": "/orders",
    "plugins": {
        "proxy-rewrite": {
            "uri": "/getOrder",
            "scheme": "http",
        }
    },
    "upstream": {
        "type": "roundrobin",
        "nodes": {
            "127.0.0.1:80": 1
        }
    }
}'

आप API वर्जनिंग ऑपरेशन के लिए भी प्लगइन का उपयोग कर सकते हैं।

• response-rewrite प्लगइन का उपयोग करके सर्वर-साइड प्रतिक्रियाओं को रीराइट करें

जब हमारे ऐतिहासिक API में अनस्टैंडर्ड प्रतिक्रिया स्टेटस कोड होते हैं, तो हम response-rewrite का उपयोग करके प्रतिक्रिया को प्रॉक्सी कर सकते हैं ताकि प्रतिक्रिया स्टेटस कोड को संशोधित किया जा सके।

curl http://127.0.0.1:9080/apisix/admin/routes/1  -H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PUT -d '
{
    "methods": ["GET"],
    "uri": "/orders",
    "plugins": {
        "response-rewrite": {
            "status_code": 201,
            "body": "{\"code\":\"ok\",\"message\":\"new json body\"}",
            "vars":[
                [ "status","==",200 ]
            ]
        }
    },
    "upstream": {
        "type": "roundrobin",
        "nodes": {
            "127.0.0.1:80": 1
        }
    }
}'

उपरोक्त उदाहरण /orders पाथ के लिए API अनुरोध में 200 की स्थिति को 201 में बदलने का प्रतिनिधित्व करता है।

चूंकि APISIX बहुत समृद्ध प्लगइन्स का समर्थन करता है, मैं आपसे और अधिक तरीकों का पता लगाने की उम्मीद करता हूं।

सारांश

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