API गेटवे और रिवर्स प्रॉक्सी (Nginx + Spring Cloud Gateway) · पाठ

Nginx से API संस्करण प्रबंधन

विभिन्न API संस्करणों का समर्थन करने के लिए Nginx कॉन्फ़िगर कीजिए, जिससे सहज अपग्रेड और पिछली संगतता संभव हो।

पाठ 1, कुल 4 में से11 चरण

Nginx से API संस्करण प्रबंधन, CoddyKit पर API गेटवे और रिवर्स प्रॉक्सी (Nginx + Spring Cloud Gateway) का एक निःशुल्क पाठ है। यह 4 में से 1वाँ पाठ है। आप नीचे पूरा पाठ निःशुल्क पढ़ सकते हैं—फिर अंतर्निहित कोड संपादक और 24/7 एआई ट्यूटर के साथ ब्राउज़र में इसका व्यावहारिक अभ्यास कर सकते हैं। यह API गेटवे और रिवर्स प्रॉक्सी (Nginx + Spring Cloud Gateway) सीखने के मार्ग का हिस्सा है और आपकी प्रगति वेब तथा CoddyKit ऐप पर सिंक होती रहती है। API गेटवे और रिवर्स प्रॉक्सी (Nginx + Spring Cloud Gateway) पाठ्यक्रम में कुल 4 पाठ शामिल हैं।

API संस्करण निर्धारण क्या है

जब आप API बनाते हैं, तो वे समय के साथ अक्सर बदलते रहते हैं। नई सुविधाएँ जोड़ी जाती हैं, पुरानी हटाई जाती हैं या तर्क को अपडेट किया जाता है।

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

इससे आपके API के विभिन्न संस्करण एक साथ चल सकते हैं और पुराने तथा नए क्लाइंट दोनों एक साथ समर्थित रहते हैं।

संस्करण निर्धारण क्यों महत्वपूर्ण है

कल्पना कीजिए कि आप अपना API अपडेट करते हैं और अचानक पुराने API का उपयोग करने वाले सभी ऐप काम करना बंद कर देते हैं। यह अच्छा अनुभव नहीं है!

पश्चगामी संगतता: यह सुनिश्चित करती है कि पुराने क्लाइंट काम करते रहें।
नियंत्रित अपग्रेड: क्लाइंट को अपनी गति से नए संस्करणों पर जाने की अनुमति देता है।
जोखिम प्रबंधन: परिवर्तनों को अलग रखकर व्यापक समस्याओं का जोखिम कम करता है।

संस्करण निर्धारण के सामान्य तरीके

API संस्करण बताने के कई तरीके हैं:

URL पथ: /api/v1/users
कस्टम हेडर: X-API-Version: 1
क्वेरी पैरामीटर: /api/users?version=1

Nginx के लिए, URL पथ द्वारा संस्करण निर्धारण अक्सर लागू करने का सबसे सरल और सामान्य तरीका है। इसके लिए location ब्लॉक का उपयोग किया जाता है, जिस पर हम ध्यान केंद्रित करेंगे।

URL-आधारित संस्करण निर्धारण के लिए Nginx

Nginx विशिष्ट URL पैटर्न से मिलान करने के लिए location ब्लॉक का उपयोग करता है। यह पथ में मौजूद संस्करण संख्या के आधार पर अनुरोधों को रूट करने के लिए बिल्कुल उपयुक्त है।

उदाहरण के लिए, /api/v1/ के अनुरोध एक बैकएंड को भेजे जा सकते हैं, जबकि /api/v2/ के अनुरोध दूसरे बैकएंड को भेजे जा सकते हैं।

इससे आप अपने API अनुप्रयोग के अलग-अलग संस्करण परिनियोजित कर सकते हैं, जिनमें से प्रत्येक अपना विशिष्ट संस्करण उपलब्ध कराता है।

API संस्करण 1 सेट अप करना

आइए Nginx को इस तरह कॉन्फ़िगर करें कि /api/v1/ के अनुरोध हमारे पहले API संस्करण को चलाने वाले बैकएंड सर्वर पर भेजे जाएँ।

हम अपनी बैकएंड सेवा के लिए एक upstream ब्लॉक और फिर अनुरोधों को प्रॉक्सी करने के लिए एक location ब्लॉक परिभाषित करेंगे।

http {
  upstream api_v1_backend {
    server 192.168.1.10:8080;
  }

  server {
    listen 80;
    server_name example.com;

    location /api/v1/ {
      proxy_pass http://api_v1_backend/;
      proxy_set_header Host $host;
    }
  }
}

API संस्करण 2 जोड़ना

अब अपने API का नया संस्करण प्रस्तुत करते हैं। हम /api/v2/ के लिए अलग upstream और location ब्लॉक सेट अप करेंगे और अनुरोधों को अलग बैकएंड सर्वर पर भेजेंगे।

इससे पता चलता है कि Nginx API संस्करण के आधार पर ट्रैफ़िक को पूरी तरह अलग अनुप्रयोग परिनियोजनों की ओर भेज सकता है।

http {
  upstream api_v1_backend {
    server 192.168.1.10:8080;
  }

  upstream api_v2_backend {
    server 192.168.1.11:8081;
  }

  server {
    listen 80;
    server_name example.com;

    location /api/v1/ {
      proxy_pass http://api_v1_backend/;
      proxy_set_header Host $host;
    }

    location /api/v2/ {
      proxy_pass http://api_v2_backend/;
      proxy_set_header Host $host;
    }
  }
}

रूट/डिफ़ॉल्ट संस्करण संभालना

यदि कोई क्लाइंट संस्करण निर्दिष्ट न करे, तो क्या होगा? आप Nginx को नवीनतम संस्करण पर रीडायरेक्ट करने या डिफ़ॉल्ट संस्करण उपलब्ध कराने के लिए कॉन्फ़िगर कर सकते हैं।

rewrite नियम का उपयोग करके, यदि क्लाइंट बिना संस्करण के /api/ का अनुरोध करता है, तो आप URI को आंतरिक रूप से /api/v2/ पर निर्देशित करने के लिए बदल सकते हैं।

http {
  # ... upstream blocks ...

  server {
    listen 80;
    server_name example.com;

    # Redirect /api/ to /api/v2/ internally
    location = /api/ {
      rewrite ^ /api/v2/ permanent;
    }

    location /api/v1/ {
      proxy_pass http://api_v1_backend/;
      proxy_set_header Host $host;
    }

    location /api/v2/ {
      proxy_pass http://api_v2_backend/;
      proxy_set_header Host $host;
    }
  }
}

उपसर्ग मिलान और अंतिम स्लैश

ध्यान रखें कि location ब्लॉक किस प्रकार मिलान करते हैं। location /api/v1 का मिलान /api/v1, /api/v1/ और /api/v1something से होगा।

अंतिम स्लैश वाले location /api/v1/ का उपयोग सामान्यतः अधिक सुरक्षित है, क्योंकि यह /api/v1/ और उसके उपपथों (जैसे, /api/v1/users) से मिलान करता है, लेकिन /api/v10 से नहीं।

proxy_pass निर्देश अंतिम स्लैश को भी संभालता है। यदि proxy_pass http://backend/; में अंतिम स्लैश है, तो Nginx URI के मिलान किए गए भाग को हटाकर उसे आगे भेजता है।

संस्करण निर्धारण की सर्वोत्तम प्रथाएँ

अपने API का संस्करण निर्धारण सुचारु और प्रभावी बनाने के लिए:

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

Nginx संस्करण निर्धारण प्रश्नोत्तरी

निम्नलिखित Nginx कॉन्फ़िगरेशन पर विचार करें। http://example.com/api/v1/products का अनुरोध किस proxy_pass गंतव्य पर भेजा जाएगा?

server {
  listen 80;
  server_name example.com;

  location /api/v1/ {
    proxy_pass http://backend_old_api/;
  }

  location /api/v2/ {
    proxy_pass http://backend_new_api/;
  }

  location / {
    proxy_pass http://default_backend/;
  }
}

इंटरैक्टिव पाठ में इसका उत्तर दें

पुनरावलोकन: Nginx के साथ API संस्करण निर्धारण

आपने Nginx का उपयोग करके API संस्करण निर्धारण लागू करना सीखा है!

संस्करण निर्धारण API परिवर्तनों और क्लाइंट संगतता को प्रबंधित करने में मदद करता है।
Nginx के location ब्लॉक URL-आधारित संस्करण निर्धारण के लिए आदर्श हैं।
आप अलग-अलग API संस्करणों को अलग-अलग बैकएंड सेवाओं पर भेज सकते हैं।
rewrite नियमों का उपयोग करके आप डिफ़ॉल्ट या बिना संस्करण वाले अनुरोधों को संभाल सकते हैं।

इससे आप सभी उपयोगकर्ताओं के लिए सेवा बनाए रखते हुए अपने API को सुचारु रूप से विकसित कर सकते हैं।

शुरुआत निःशुल्क

एआई शिक्षक के साथ API गेटवे और रिवर्स प्रॉक्सी (Nginx + Spring Cloud Gateway) सीखें — निःशुल्क

अपने ब्राउज़र में वास्तविक कोड लिखें और चलाएँ, चौबीसों घंटे एआई शिक्षक से तुरंत सहायता पाएँ, और वेब या ऐप पर वहीं से शुरू करें जहाँ आपने छोड़ा था।

पाठ्यक्रम: 12
पाठ: 48

निःशुल्क सीखना शुरू करें पूरा पाठ्यक्रम देखें

अक्सर पूछे जाने वाले प्रश्न

क्या “Nginx से API संस्करण प्रबंधन” पाठ निःशुल्क है?

हाँ—“Nginx से API संस्करण प्रबंधन” का पूरा पाठ यहाँ वेब पर निःशुल्क पढ़ा जा सकता है। इंटरैक्टिव अभ्यास (अंतर्निहित कोड संपादक और 24/7 एआई ट्यूटर) करने और API गेटवे और रिवर्स प्रॉक्सी (Nginx + Spring Cloud Gateway) पाठ्यक्रम का बाकी हिस्सा अनलॉक करने के लिए CoddyKit PRO लें। API गेटवे और रिवर्स प्रॉक्सी (Nginx + Spring Cloud Gateway) पाठ्यक्रम में कुल 4 पाठ शामिल हैं।

“Nginx से API संस्करण प्रबंधन” में मैं क्या सीखूँगा?

विभिन्न API संस्करणों का समर्थन करने के लिए Nginx कॉन्फ़िगर कीजिए, जिससे सहज अपग्रेड और पिछली संगतता संभव हो। आप ब्राउज़र में सीधे चलाए जाने वाले व्यावहारिक कोड के साथ API गेटवे और रिवर्स प्रॉक्सी (Nginx + Spring Cloud Gateway) का अभ्यास करते हैं, और पाठ पूरा करते समय 24/7 एआई ट्यूटर आपके प्रश्नों के उत्तर देता है।

क्या API गेटवे और रिवर्स प्रॉक्सी (Nginx + Spring Cloud Gateway) शुरू करने के लिए मुझे किसी अनुभव की आवश्यकता है?

पहले के अनुभव की आवश्यकता नहीं है। CoddyKit पर API गेटवे और रिवर्स प्रॉक्सी (Nginx + Spring Cloud Gateway) शुरुआती से लेकर उन्नत शिक्षार्थियों तक सभी के लिए व्यवस्थित किया गया है, इसलिए आप यहीं से या शुरुआत से सीखना शुरू कर सकते हैं और अपनी गति से आगे बढ़ सकते हैं। यह 4 में से 1वाँ पाठ है।

“Nginx से API संस्करण प्रबंधन” पाठ पूरा करने में कितना समय लगता है?

CoddyKit का अधिकांश पाठ लगभग 5–10 मिनट में पूरा हो जाता है। हर पाठ छोटा और संवादात्मक है, इसलिए आप लगातार प्रगति करते हैं और वेब या ऐप पर वहीं से सीखना जारी रख सकते हैं जहाँ आपने छोड़ा था।

क्या मैं इस API गेटवे और रिवर्स प्रॉक्सी (Nginx + Spring Cloud Gateway) पाठ में कोड लिख और चला सकता हूँ?

हाँ। हर API गेटवे और रिवर्स प्रॉक्सी (Nginx + Spring Cloud Gateway) पाठ में एक अंतर्निर्मित कोड संपादक शामिल है, जिससे आप सीधे अपने ब्राउज़र में वास्तविक कोड लिख और चला सकते हैं और तुरंत एआई प्रतिक्रिया पा सकते हैं—स्थानीय सेटअप की आवश्यकता नहीं है।

इस पाठ्यक्रम के सभी पाठ

← API गेटवे और रिवर्स प्रॉक्सी (Nginx + Spring Cloud Gateway) पर वापस जाएँ