API वार्मर

वास्तविक तरीकों, हेडर, कुकीज़, बॉडी और कॉन्फिग मैट्रिसेस के साथ REST और GraphQL एंडपॉइंट को गर्म रखें।

13 min read

एपीआई बिल्कुल वेब पेजों की तरह ठंडे हो जाते हैं। यदि JSON प्रतिक्रिया बनाना महंगा है और आपके CDN या गेटवे पर कैश किया गया है, तो समाप्ति के बाद पहला ग्राहक वही जुर्माना अदा करेगा जो एक वेबसाइट विज़िटर को देना होगा।

API वार्मर इसे हल करें। उन्हें खाता → API वार्मर्स के अंतर्गत वेबसाइट वार्मर्स से अलग से प्रबंधित किया जाता है, और उनकी अपनी योजना सीमाएँ होती हैं।

वेबसाइट वार्मर से अलग

एपीआई वार्मर अपनी पात्रता के साथ एक विशिष्ट विशेषता हैं।यदि अनुभाग गायब है या लॉक है, तो आपकी योजना में वे शामिल नहीं हैं - [योजनाएं और सीमाएं] (/documentation/plans-and-limits) देखें।

एक का उपयोग कब करें

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

एक API वार्मर उन एंडपॉइंट्स के लिए उपयोगी नहीं है जो कभी कैश नहीं होते हैं, या जो प्रति उपयोगकर्ता अद्वितीय होते हैं और इसलिए भरने के लिए कोई साझा कैश्ड कॉपी नहीं होती है।

API वार्मर बनाना

  1. 1

    API होस्टनाम सत्यापित करें

    एंडपॉइंट यूआरएल को बिल्कुल वेबसाइट वार्मर की तरह एक सत्यापित होस्टनाम का उपयोग करना चाहिए।[होस्टनाम सत्यापन] (/documentation/hostname-verification) देखें।

  2. 2

    वार्मर का नाम बताएं और इसे निष्क्रिय छोड़ दें

    पहले कॉन्फ़िगर करें, संतुष्ट होने पर सक्रिय करें।

  3. 3

    एक या अधिक समापनबिंदु जोड़ें

    प्रत्येक समापन बिंदु में एक URL और एक HTTP विधि होती है, और वैकल्पिक रूप से एक लेबल, बॉडी और सामग्री प्रकार होता है।

  4. 4

    यदि समापन बिंदु को इसकी आवश्यकता है तो प्रमाणीकरण जोड़ें

    ग्लोबल हेडर और कुकीज़ वार्मर द्वारा किए गए प्रत्येक अनुरोध पर लागू किए जाते हैं।

  5. 5

    वैकल्पिक रूप से कॉन्फ़िगरेशन मैट्रिक्स के साथ विस्तार करें

    लगभग एक जैसे दर्जनों वार्मर बनाए बिना कई प्रकार - स्थान, किरायेदार, आईडी - को कवर करें।

  6. 6

    दर और अंतराल सेट करें, फिर सक्रिय करें

    वेबसाइट वार्मर के समान ही विचार: आपके कैश TTL को हरा देने के लिए अक्सर पर्याप्त गर्म, धीरे-धीरे इतना कि नुकसान न हो।

अंतिमबिंदुओं

वार्मर में प्रत्येक समापन बिंदु स्वतंत्र रूप से कॉन्फ़िगर किया गया है:

लेबल
एक वैकल्पिक मानव-पठनीय नाम, इसलिए समापन बिंदुओं की एक लंबी सूची पठनीय बनी रहती है।
WordPress
सत्यापित होस्टनाम पर पूरा समापन बिंदु पता। PATH आयाम के साथ जोड़े जाने पर इसमें {id} या :id जैसे पथ प्लेसहोल्डर शामिल हो सकते हैं।
तरीका
आपकी योजना के आधार पर GET, POST, और अन्य। योजनाएं आम तौर पर डिफ़ॉल्ट रूप से GET और HEAD की अनुमति देती हैं, उच्च स्तरों पर अधिक विधियों के साथ।
शिष्टाचार
REST या GRAPHQL. GraphQL चुनने से ऑपरेशन और क्वेरी फ़ील्ड का पता चलता है।
बॉडी टेम्पलेट का अनुरोध करें
भेजने के लिए शरीर, उन तरीकों के लिए जो एक को ले जाते हैं। API अनुरोध निकाय पात्रता की आवश्यकता है।
WordPress
अनुरोध निकाय का सामग्री प्रकार, आमतौर पर application/json
नपुंसक
समापन बिंदु को दो बार कॉल करने के लिए सुरक्षित के रूप में चिह्नित करता है, जिससे ठंडा/गर्म डबल फ़ेच सक्षम होता है जो सुधार को मापता है। इसे केवल तभी सक्षम करें जब दो बार कॉल करने पर वास्तव में कोई दुष्प्रभाव न हो।
सक्रिय
क्या यह विशिष्ट समापन बिंदु रन में शामिल है। किसी एक समापन बिंदु को हटाए बिना उसे अस्थायी रूप से अक्षम करने के लिए उपयोगी।

लेखन संचालन को निष्क्रिय चिह्नित करने में सावधानी बरतें

एंडपॉइंट पर एक डबल फ़ेच जो ऑर्डर बनाता है, ईमेल भेजता है, या चार्ज कार्ड दो बार करेगा। किसी समापन बिंदु को केवल तभी चिह्नित करें जब इसे दोहराना वास्तव में हानिरहित हो।

कॉन्फ़िगरेशन मैट्रिसेस

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

एक कॉन्फिग मैट्रिक्स इसे हल करता है। आप कई मानों के साथ आयामों को परिभाषित करते हैं, और Cache Rocket पूर्ण कार्टेशियन उत्पाद को व्यक्तिगत गर्म अनुरोधों में विस्तारित करता है।

आयाम प्रकारमूल्यों को इंजेक्ट करता हैउदाहरण
QUERYक्वेरी स्ट्रिंगlocale=en, locale=nl, locale=de
HEADERएक अनुरोध शीर्षलेखX-Tenant: acme, X-Tenant: globex
COOKIEएक कुकीcurrency=EUR, currency=USD
PATHURL में एक {placeholder}{id}1, 2, 3

एक काम किया हुआ उदाहरण

text
Endpoint:  GET https://api.example.com/v1/products/{category}

Dimensions:
  PATH   category = shoes, bags, hats
  QUERY  locale   = en, nl

Expands to 6 warm requests:
  /v1/products/shoes?locale=en
  /v1/products/shoes?locale=nl
  /v1/products/bags?locale=en
  /v1/products/bags?locale=nl
  /v1/products/hats?locale=en
  /v1/products/hats?locale=nl

संयोजन तेजी से बढ़ते हैं

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

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

प्रमाणीकरण

वैश्विक अनुरोध हेडर और कुकीज़ वार्मर द्वारा उत्पन्न प्रत्येक संस्करण पर लागू होते हैं। यहीं पर Authorization हेडर या सत्र कुकी जाती है।

विशिष्ट लेख शीर्षलेख
text
Authorization: Bearer YOUR_LONG_LIVED_TOKEN
X-Api-Key: YOUR_API_KEY

वास्तविक ग्राहकों द्वारा वास्तव में अनुरोध किए जाने वाले वेरिएंट को गर्म करें

यदि आपका कैश Authorization से भिन्न होता है, तो सर्विस टोकन के साथ वार्मिंग उस टोकन से जुड़ी कैश प्रविष्टि को भर देती है - जिसे कोई भी वास्तविक ग्राहक कभी भी हिट नहीं करेगा। साझा, कैश करने योग्य प्रतिक्रियाओं के लिए, उसी तरह गर्म करें जैसे एक सामान्य ग्राहक एंडपॉइंट को कॉल करता है।

टोकन समाप्त हो गए. यदि कोई API वार्मर अचानक 401 लौटाना शुरू कर देता है, तो हार्ड-कोडित टोकन जांचने वाली पहली चीज़ है।

GraphQL

GraphQL को अपने स्वयं के उपचार की आवश्यकता है क्योंकि प्रदर्शन विशिष्ट ऑपरेशन पर निर्भर करता है, समापन बिंदु पथ पर नहीं। /graphql को एक बार मारने से आपको कुछ नहीं मिलता; आपके तीन सबसे भारी प्रश्नों को गर्म करना आपको सब कुछ बताता है।

एंडपॉइंट के प्रोटोकॉल को GraphQL पर सेट करें, फिर आपूर्ति करें:

  • GraphQL ऑपरेशन — चाहे यह query हो या mutation हो। वार्मिंग उत्परिवर्तन लगभग कभी भी उचित नहीं होता है।
  • GraphQL क्वेरी - भेजने के लिए ऑपरेशन दस्तावेज़।
  • वेरिएबल - उन्हें अनुरोध बॉडी टेम्पलेट के माध्यम से, या कई वेरिएबल सेट को गर्म करने के लिए मैट्रिक्स आयाम मान के रूप में आपूर्ति करें।

Note

GraphQL वार्मिंग को API वार्मर के शीर्ष पर, अपनी स्वयं की योजना पात्रता द्वारा गेट किया जाता है।

ओपनएपीआई आयात

समर्थित योजनाओं पर आप एंडपॉइंट को टाइप करने के बजाय सीधे OpenAPI 3 विनिर्देश से आयात कर सकते हैं। JSON या YAML विनिर्देश के URL को चिपकाएँ और आयात पर क्लिक करें; खोजे गए एंडपॉइंट को वार्मर में जोड़ा जाता है, जो छंटाई और समायोजन के लिए तैयार होता है।

Tip

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

सीमाएँ और शेड्यूलिंग

अधिकतम प्रति मिनट गर्म होता है
इस API वार्मर के लिए दर सीमा, एक वेबसाइट वार्मर पर अधिकतम URLs प्रति मिनट के बराबर है।
ब्रेक का अनुरोध
हार मानने से पहले प्रतिक्रिया के लिए कब तक इंतजार करना होगा?
ऑटो प्रारंभ अंतराल
कितनी बार एक नया वार्म पास शुरू होता है, सेकंडों में।
कतार अंतराल
चक्र के भीतर पुन: कतारबद्ध कार्य की गति।
HTTPS पर पुनः लिखें
http:// समापन बिंदु URLs को https:// में अपग्रेड करें।
गर्म कार्यक्रम
पीक और ऑफ-पीक विंडो, वेबसाइट वार्मर के समान JSON प्रारूप।[उन्नत वार्मिंग] (/documentation/advanced-warming) देखें।

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

सामान्य समस्या

सब कुछ 401 या 403 लौटता है।
ऑथ हेडर या कुकी गुम है, गलत है, या समाप्त हो गई है। लंबे समय तक चलने वाले टोकन सामान्य अपराधी हैं - जांचें कि टोकन अभी भी वैध है और घुमाया नहीं गया है।
बहुत सारे संयोजनों का हवाला देते हुए वार्मर नहीं बचाएगा।
आपका मैट्रिक्स अधिकतम योजना से आगे विस्तारित होता है। आयाम मानों को कम करें, समापन बिंदुओं को कई वार्मरों में विभाजित करें, या अपग्रेड करें।
मुझे जिस विधि की आवश्यकता है वह ड्रॉपडाउन में नहीं है।
योजनाएं प्रतिबंधित करती हैं कि किन HTTP विधियों की अनुमति है। निचले स्तर आमतौर पर केवल GET और HEAD की अनुमति देते हैं।
वार्मिंग साफ-सुथरी चलती है लेकिन वास्तविक ग्राहकों के लिए प्रतिक्रियाएँ अभी भी धीमी हैं।
आप संभवतः ग्राहकों के अनुरोध से भिन्न कैश वैरिएंट भर रहे हैं - आमतौर पर Authorization हेडर, एक कुकी, या एक हेडर के कारण आपका CDN भिन्न होता है। वास्तविक ग्राहक द्वारा भेजे गए सटीक अनुरोध की तुलना वार्मर द्वारा भेजे गए अनुरोध से करें।
क्या मैं एक समापन बिंदु को गर्म कर सकता हूं जिसके लिए हस्ताक्षरित, अल्पकालिक टोकन की आवश्यकता है?
विश्वसनीय रूप से नहीं, क्योंकि वार्मर प्रति रन एक नया हस्ताक्षर उत्पन्न नहीं कर सकता है। या तो कैश करने योग्य अप्रमाणित संस्करण को उजागर करें, या जहां वह सुरक्षित हो वहां लंबे समय तक चलने वाले सेवा टोकन का उपयोग करें।