API वार्मर
वास्तविक तरीकों, हेडर, कुकीज़, बॉडी और कॉन्फिग मैट्रिसेस के साथ REST और GraphQL एंडपॉइंट को गर्म रखें।
13 min read
एपीआई बिल्कुल वेब पेजों की तरह ठंडे हो जाते हैं। यदि JSON प्रतिक्रिया बनाना महंगा है और आपके CDN या गेटवे पर कैश किया गया है, तो समाप्ति के बाद पहला ग्राहक वही जुर्माना अदा करेगा जो एक वेबसाइट विज़िटर को देना होगा।
API वार्मर इसे हल करें। उन्हें खाता → API वार्मर्स के अंतर्गत वेबसाइट वार्मर्स से अलग से प्रबंधित किया जाता है, और उनकी अपनी योजना सीमाएँ होती हैं।
वेबसाइट वार्मर से अलग
एपीआई वार्मर अपनी पात्रता के साथ एक विशिष्ट विशेषता हैं।यदि अनुभाग गायब है या लॉक है, तो आपकी योजना में वे शामिल नहीं हैं - [योजनाएं और सीमाएं] (/documentation/plans-and-limits) देखें।
एक का उपयोग कब करें
| परिस्थिति | API वार्मर क्यों मदद करता है |
|---|---|
| बिना नेतृत्व वाला स्टोरफ्रंट या साइट | उत्पाद, इन्वेंट्री और सामग्री JSON प्रत्येक पेज रेंडर पर लाई जाती है। उन मार्गों को गर्म करने से पूरा अग्र भाग तेज़ रहता है। |
| एक सार्वजनिक डेवलपर API | लोकप्रिय समापन बिंदु और दस्तावेज़ीकरण उदाहरण पहले कॉल करने वाले के लिए धीमे होने के बजाय प्रतिक्रियाशील बने रहते हैं। |
| बैकएंड-फॉर-फ्रंटएंड परत | एकत्रित समापन बिंदु जो कई सेवाओं को प्रभावित करते हैं, उनका पुनर्निर्माण करना महंगा है। उन्हें गर्म करने से मोबाइल और वेब क्लाइंट की सुरक्षा होती है। |
| भारी GraphQL संचालन | कुछ क्वेरीज़ आम तौर पर ट्रैफ़िक पर हावी रहती हैं। उन विशिष्ट परिचालनों को गर्म करना /graphql को एक बार हिट करने से कहीं अधिक मायने रखता है। |
एक API वार्मर उन एंडपॉइंट्स के लिए उपयोगी नहीं है जो कभी कैश नहीं होते हैं, या जो प्रति उपयोगकर्ता अद्वितीय होते हैं और इसलिए भरने के लिए कोई साझा कैश्ड कॉपी नहीं होती है।
API वार्मर बनाना
- 1
API होस्टनाम सत्यापित करें
एंडपॉइंट यूआरएल को बिल्कुल वेबसाइट वार्मर की तरह एक सत्यापित होस्टनाम का उपयोग करना चाहिए।[होस्टनाम सत्यापन] (/documentation/hostname-verification) देखें।
- 2
वार्मर का नाम बताएं और इसे निष्क्रिय छोड़ दें
पहले कॉन्फ़िगर करें, संतुष्ट होने पर सक्रिय करें।
- 3
एक या अधिक समापनबिंदु जोड़ें
प्रत्येक समापन बिंदु में एक URL और एक HTTP विधि होती है, और वैकल्पिक रूप से एक लेबल, बॉडी और सामग्री प्रकार होता है।
- 4
यदि समापन बिंदु को इसकी आवश्यकता है तो प्रमाणीकरण जोड़ें
ग्लोबल हेडर और कुकीज़ वार्मर द्वारा किए गए प्रत्येक अनुरोध पर लागू किए जाते हैं।
- 5
वैकल्पिक रूप से कॉन्फ़िगरेशन मैट्रिक्स के साथ विस्तार करें
लगभग एक जैसे दर्जनों वार्मर बनाए बिना कई प्रकार - स्थान, किरायेदार, आईडी - को कवर करें।
- 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 |
PATH | URL में एक {placeholder} | {id} → 1, 2, 3 |
एक काम किया हुआ उदाहरण
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 हेडर या सत्र कुकी जाती है।
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 भिन्न होता है। वास्तविक ग्राहक द्वारा भेजे गए सटीक अनुरोध की तुलना वार्मर द्वारा भेजे गए अनुरोध से करें। - क्या मैं एक समापन बिंदु को गर्म कर सकता हूं जिसके लिए हस्ताक्षरित, अल्पकालिक टोकन की आवश्यकता है?
- विश्वसनीय रूप से नहीं, क्योंकि वार्मर प्रति रन एक नया हस्ताक्षर उत्पन्न नहीं कर सकता है। या तो कैश करने योग्य अप्रमाणित संस्करण को उजागर करें, या जहां वह सुरक्षित हो वहां लंबे समय तक चलने वाले सेवा टोकन का उपयोग करें।