इस public APIs सूची का इस्तेमाल कैसे करें
एक API चुनिए और एक स्किल। तीन केस लिखिए: happy path, एक edge case, और एक ऐसा केस जिसमें आप फेल होने की उम्मीद करते हैं और assert करते हैं कि फेल्योर का स्वरूप सही है। यह तीसरा वाला ही है जिसे ज़्यादातर लोग छोड़ देते हैं, और यही उस suite को अलग करता है जो बग पकड़ती है उस suite से जो सिर्फ़ यह बताती है कि सर्विस ऑनलाइन है।
शुरू करने से पहले एक बात। ये साझा सर्विसेज़ हैं, जिन्हें वॉलंटियर चलाते हैं या कंपनियाँ सद्भावना के तौर पर। अपना वॉल्यूम कम रखिए, इन पर load generator मत चलाइए, और जहाँ हो सके responses को cache कीजिए।
request और response की बुनियादी बातें सीखने के लिए
JSONPlaceholder. posts, comments, users और todos वाला एक नकली REST API। यह writes स्वीकार करता है और ऐसा दिखाता है जैसे उन्हें सहेज लिया हो। प्रैक्टिस: CRUD verbs, स्टेटस कोड, और उस request में फ़र्क जो सफल हुई और उस बदलाव में जो वाकई टिका। writes असल में सेव नहीं होते — यही बात इसे responses के बजाय नतीजों पर assert करना सिखाने वाला असाधारण अच्छा सबक बनाती है।
HTTPBin. एक ऐसा endpoint जो आप जो भी भेजें वही वापस लौटा देता है, साथ ही ऐसे routes जो आपके माँगे किसी भी स्टेटस कोड को लौटाते हैं, जान-बूझकर देर करते हैं, या खराब payload भेजते हैं। प्रैक्टिस: timeouts, retries, redirect हैंडलिंग और header व्यवहार। अगर आप देखना चाहते हैं कि 503 पर आपकी suite कैसा बर्ताव करती है, तो आप माँगने भर से एक पैदा कर सकते हैं।
REST Countries. देशों का डेटा, स्थिर और अच्छी तरह डॉक्युमेंटेड स्ट्रक्चर के साथ, और किसी key की ज़रूरत नहीं। प्रैक्टिस: ऐसे payload पर schema assertions और फ़ील्ड-स्तर की validation, जो दिलचस्प होने लायक बड़ा है पर पढ़ लेने लायक छोटा भी।
pagination और बड़े कलेक्शन के लिए
PokéAPI
एक बड़ा, गहराई से आपस में जुड़ा डेटासेट, जिसमें मानक offset और limit वाला pagination है।
प्रैक्टिस: पेज-दर-पेज चलना, यह assert करना कि पूरा traversal उतनी ही count लौटाए जितनी कलेक्शन बताता है, और पेज की सीमाओं पर off-by-one गलतियाँ पकड़ना।
Open Library
किताबों और लेखकों के रिकॉर्ड, search के साथ, और ढेरों ऐसे रिकॉर्ड जिनमें फ़ील्ड गायब या असंगत हैं।
प्रैक्टिस: optional फ़ील्ड्स को सहना। असली डेटा गड़बड़ होता है, और जो suite यह मान लेती है कि हर रिकॉर्ड पूरा है, वह production के संपर्क में आते ही टूट जाएगी।
GitHub REST API
कम वॉल्यूम पर बिना authentication के चलता है, और token के साथ authenticated भी।
प्रैक्टिस: link-header pagination, conditional requests, और authenticate करने से पहले और बाद के व्यवहार का फ़र्क।
authentication और rate limits के लिए
GitHub, authenticated
प्रैक्टिस: token हैंडलिंग, scope एरर, और यह assert करना कि बिना permission वाली request सही तरीके से फेल हो, न कि किसी सामान्य तरीके से।
Open-Meteo
मौसम का पूर्वानुमान, बिना key के, और एक प्रकाशित fair-use पॉलिसी के साथ।
प्रैक्टिस: query parameter के संयोजन और समय-आधारित डेटा, जहाँ सही जवाब हर रन में बदलता है। ऐसे assertions के लिए अच्छी ट्रेनिंग जो exact match नहीं हो सकते।
फिर से HTTPBin
प्रैक्टिस: basic auth और bearer token के flows, उन endpoints पर जो खास इन्हीं के लिए बने हैं — और किसी और का quota जोखिम में डाले बिना।
किसी भी public API पर प्रैक्टिस करने लायक तीन assertions
आप जो भी सर्विस चुनें, ये वे आदतें हैं जो आपके अपने API पर भी काम आएँगी।
सिर्फ़ स्टेटस पर नहीं, body पर assert कीजिए। जहाँ कोई रिकॉर्ड होना चाहिए वहाँ खाली list लिए हुए 200 एक बग है, जिसे स्टेटस-कोड वाली assertion खुशी-खुशी पास कह देगी। यह अकेली आदत किसी भी दूसरी आदत से ज़्यादा असली खामियाँ पकड़ती है।
assert कीजिए कि फेल्योर सही तरीके से फेल हो। ऐसी चीज़ माँगिए जो मौजूद ही नहीं है और जाँचिए कि आपको सही कोड और काम लायक एरर स्ट्रक्चर मिलता है। ऐसी सर्विसेज़ आम हैं जो अंदर error object लिए 200 लौटाती हैं, और जो suite यह नहीं जानती वह हमेशा हरी रिपोर्ट देती रहेगी।
सिर्फ़ फ़ील्ड्स पर नहीं, रिश्तों पर assert कीजिए। अगर कोई post किसी user का ज़िक्र करती है, तो उस user को fetch कीजिए और जाँचिए कि वह मौजूद है। ज़्यादातर दिलचस्प बग किसी एक endpoint के अंदर नहीं, दो endpoints के बीच रहते हैं।
किसी एक पर एजेंट लगाना
अगर आप अपनी सर्विस पर आज़माने से पहले देखना चाहते हैं कि जनरेट की गई coverage कैसी दिखती है, तो public API इसके लिए सुरक्षित जगह है। यहाँ न कोई डेटा गंदा होने वाला है और न कोई एनवायरनमेंट टूटने वाला।
किसी प्रोजेक्ट को base URL पर लगाइए और discovery को endpoints की सूची बनाने दीजिए, फिर कुछ भी चलाने से पहले जनरेट हुआ प्लान पढ़िए। दिलचस्प हिस्सा प्लान ही है। आगे बढ़ते हुए दो चीज़ें देखने लायक हैं।
क्या यह values को hardcode करने के बजाय उन्हें पकड़ता है? create कॉल एक identifier लौटाती है और अगली कॉल को उसी का इस्तेमाल करना चाहिए। hardcoded identifiers ही आम वजह हैं कि कोई suite सिर्फ़ एक बार चलती है।
क्या यह एक-दूसरे पर निर्भर कॉल्स का क्रम सही रखता है? आप ऐसी post पर comment fetch नहीं कर सकते जो कभी बनी ही नहीं। देखिए कि प्लान यह समझता है या बस endpoints को वर्णमाला के क्रम में गिना देता है।
फिर इसे चलाइए और फेल्योर पढ़िए। किसी public API पर ज़्यादातर फेल्योर सर्विस की नहीं, आपकी अपनी धारणाओं की होंगी — और सबक ठीक यही है।
अगर आप टेस्ट कोड खुद अपने पास रखना चाहते हैं, तो CLI बैकएंड काम के लिए अलग रास्ता देता है: कॉल्स और assertions आप खुद Python में लिखते हैं, बताते हैं कि हर टेस्ट को क्या चाहिए और वह क्या पैदा करता है, और cleanup को अपने आप में एक टेस्ट के तौर पर मार्क करते हैं। शुरू में मेहनत ज़्यादा है और इससे suite आपकी repository में रहती है — जो कुछ टीमों को चाहिए और कुछ को नहीं।
प्रैक्टिस से अपनी सर्विस तक पहुँचना
किसी public API पर प्रैक्टिस करने और अपने API को टेस्ट करने के बीच की खाई दिखने से बड़ी है, और यह जानना कि मुश्किल कहाँ अचानक बढ़ती है, कुछ झुंझलाहट बचा देता है।
आपके नज़रिए से public APIs stateless हैं: आप पढ़ते हैं, और जो लिखते हैं वह या तो टिकता नहीं या मायने नहीं रखता। आपकी अपनी सर्विस इसका उलटा है। जिस पल आप कुछ असली टेस्ट करते हैं, आपके हिस्से आ जाता है ऐसा authentication जो खत्म हो जाता है, ऐसे रिकॉर्ड जिन्हें दूसरे रिकॉर्ड से पहले मौजूद होना ज़रूरी है, ऐसी values जो सिर्फ़ runtime पर बनती हैं, और अपने पीछे सफ़ाई करने की ज़िम्मेदारी।
इनमें से कोई भी किसी ट्यूटोरियल में नहीं मिलता और ये सभी पहले ही हफ़्ते सामने आ जाते हैं। इसलिए public-API वाले दौर को assertions सीखने का समय मानिए, जो पूरी तरह आगे काम आता है, और state संभालना एक अलग चीज़ मानिए जिसे आप बाद में सीखेंगे, न कि उसी स्किल का अगला हिस्सा।
इनके साथ क्या नहीं करना चाहिए
इन्हें load testing के लिए मत इस्तेमाल कीजिए। ये फ्री हैं, साझा हैं, और इनका बिल कोई और भरता है।
इनमें से किसी पर production निर्भरता मत बनाइए। शर्तें बदलती हैं, प्रोजेक्ट आर्काइव हो जाते हैं, और वॉलंटियर थक जाते हैं।
JSONPlaceholder पर पास होती suite को इस बात का सबूत मत मानिए कि आपका अपना API सही है। यह इतना बताती है कि आपका टेस्ट सेटअप काम करता है — जो वाकई काम की बात है, पर कहीं छोटा दावा है।
असली सर्विस पर यह आज़माना
assertion की आदतें जम जाने के बाद, अपने API तक की छलाँग वहीं है जहाँ state की दिक्कतें शुरू होती हैं, और यही हिस्सा TestSprite प्रोडक्ट के तौर पर संभालता है। Auto-Authentication पूरे रन में सेशन ज़िंदा रखता है। Dynamic Variables किसी create कॉल से identifier उठाकर delete कॉल तक पहुँचाते हैं। Dependency Chains तय करते हैं कि पहले क्या होना चाहिए। Auto-Cleanup रन में बनी चीज़ें हटा देता है।
अपनी सर्विस पर शुरुआत ऊपर दी गई public-API कसरत जैसी ही दिखती है: प्रोजेक्ट को base URL पर लगाइए, discovery को endpoints की सूची बनाने दीजिए, और कुछ भी चलने से पहले जनरेट हुआ प्लान पढ़िए। फ़र्क यह है कि अब प्लान authorization और boundary केस भी समेटता है, और रन अपने पीछे कुछ नहीं छोड़ता।
पहले किसी public API पर इसे आज़माना सुरक्षित है, क्योंकि वहाँ गंदा करने को कोई डेटा नहीं है, और प्लान आपको टूल के बारे में नतीजों से ज़्यादा बताता है।
मुझे किससे शुरू करना चाहिए?
पहले एक घंटे के लिए JSONPlaceholder, क्योंकि यहाँ कुछ गलत हो ही नहीं सकता। उसके बाद HTTPBin, क्योंकि यह आपको जान-बूझकर फेल्योर पैदा करने देता है, और सीखना फेल्योर पर प्रैक्टिस करने में ही है।
क्या इनमें से किसी के लिए API key चाहिए?
इस सूची में ज़्यादातर बिना key के चलते हैं। GitHub कम वॉल्यूम पर बिना authentication के चलता है, और token लेना ठीक इसीलिए फायदेमंद है कि वह आपको authenticated flows की प्रैक्टिस करने देता है।
क्या मैं इन्हें CI pipeline में इस्तेमाल कर सकता हूँ?
छोटी ट्यूटोरियल suite के लिए, हाँ। हर commit पर चलने वाली किसी भी चीज़ के लिए, इसके बजाय local mock पर चलाइए। CI को किसी वॉलंटियर-संचालित सर्विस पर लगाना ही वह तरीका है जिससे एक काम का फ्री रिसोर्स फ्री रहना बंद कर देता है।
यह public APIs के किसी Postman collection से कैसे अलग है?
collection आपको requests देता है। यह सूची इस आधार पर बनी है कि हर सर्विस क्या सिखाती है, और जब मकसद टेस्टिंग में बेहतर होना है, न कि एक कॉल को सफल कराना, तब यही ज़्यादा मायने रखता है।
जनरेट की गई coverage देखने का सबसे तेज़ तरीका क्या है?
किसी प्रोजेक्ट को public base URL पर लगाइए, discovery को endpoints की सूची बनाने दीजिए, और कुछ भी चलाने से पहले प्लान पढ़िए। प्लान आपको टूल के बारे में नतीजों से ज़्यादा बताता है।
एक API चुनिए, एक स्किल की प्रैक्टिस कीजिए, और फेल होने वाला केस हमेशा लिखिए।
अच्छी coverage कैसी दिखती है, यह सीखने के लिए public APIs सबसे सुरक्षित जगह हैं, क्योंकि यहाँ तोड़ने को कुछ नहीं है। जब तैयार हो जाएँ, तो यही तरीका अपनी सर्विस पर लगाइए और bodies, फेल्योर और रिश्तों पर assert करने की आदत बनाए रखिए।