API टेस्टर
सीधे ब्राउज़र में HTTP रिक्वेस्ट भेजें और रिस्पॉन्स देखें — एक पूरी सुविधाओं वाला API क्लाइंट।
रिक्वेस्ट भेजने पर रिस्पॉन्स यहाँ दिखेगा।
अभी कोई कलेक्शन नहीं है। एक बनाने के लिए सेव पर क्लिक करें।
भेजी गई रिक्वेस्ट यहाँ दिखेंगी।
उपयोग के उदाहरण
कोड लिखने से पहले API एंडपॉइंट टेस्ट करना
अपने ऐप में जोड़ने से पहले देखें कि कोई GET या POST एंडपॉइंट क्या रिस्पॉन्स और स्टेटस कोड देता है, हेडर समेत।
ऑथेंटिकेशन हेडर डीबग करना
बिना कोई अलग ऐप इंस्टॉल किए Bearer टोकन या बेसिक ऑथ क्रेडेंशियल डालकर देखें कि सर्वर उन्हें सही से स्वीकार करता है या नहीं।
डेवलपमेंट के दौरान रिक्वेस्ट हिस्ट्री देखना
भेजी गई रिक्वेस्ट अपने आप रिकॉर्ड हो जाती हैं, ताकि आप हर बार दोबारा टाइप किए बिना एक क्लिक में फिर से भेज सकें या तुलना कर सकें।
रिक्वेस्ट को कलेक्शन में व्यवस्थित करना
एक ही API के सभी एंडपॉइंट जैसी संबंधित रिक्वेस्ट को किसी नामित कलेक्शन में सेव करें, ताकि बाद में एक क्लिक में वापस लोड कर सकें।
अक्सर पूछे जाने वाले सवाल
क्या मेरा डेटा सर्वर पर भेजा जाता है?
हमारे सर्वर पर नहीं। यह टूल आपके ब्राउज़र से सीधे आपकी दी गई URL पर रिक्वेस्ट भेजता है — कुछ भी हमारे सर्वर से होकर नहीं गुज़रता। रिक्वेस्ट हिस्ट्री और सेव की गई वैल्यूज़ भी सिर्फ़ आपके ब्राउज़र के लोकल स्टोरेज में रहती हैं।
कुछ रिक्वेस्ट नेटवर्क एरर के साथ क्यों फ़ेल होती हैं?
ब्राउज़र क्रॉस-ऑरिजिन रिक्वेस्ट (CORS) को तब तक ब्लॉक करते हैं जब तक टारगेट सर्वर साफ़ तौर पर इजाज़त न दे। अगर कोई रिक्वेस्ट यहाँ फ़ेल होती है लेकिन किसी डेस्कटॉप API क्लाइंट में काम करती है, तो संभावना है कि सर्वर ब्राउज़र के लिए ज़रूरी CORS हेडर नहीं भेज रहा — यह इस टूल की गड़बड़ी नहीं, बल्कि ब्राउज़र की सुरक्षा सीमा है।
क्या असली API टोकन से टेस्ट करना सुरक्षित है?
आपके टोकन सिर्फ़ आपकी बताई गई API पर रिक्वेस्ट भेजने के लिए इस्तेमाल होते हैं, और सुविधा के लिए (बाद में दोबारा भेजने के लिए) आपके ब्राउज़र के लोकल स्टोरेज में रखे जाते हैं — कहीं और नहीं भेजे जाते। फिर भी, साझा या सार्वजनिक कंप्यूटर पर संवेदनशील प्रोडक्शन क्रेडेंशियल से टेस्ट करने से बचें।
कौन-कौन से HTTP मेथड सपोर्टेड हैं?
GET, POST, PUT, PATCH, DELETE, HEAD और OPTIONS सपोर्टेड हैं।
क्या मैं रिक्वेस्ट को कलेक्शन में सेव कर सकता हूँ?
हाँ — मौजूदा रिक्वेस्ट को नए या पहले से मौजूद कलेक्शन में सेव करने के लिए Send बटन के बगल में मौजूद Save बटन पर क्लिक करें। सेव किए गए कलेक्शन और रिक्वेस्ट आपके ब्राउज़र के लोकल स्टोरेज में, अपने आप बनने वाली हिस्ट्री से अलग रखे जाते हैं।
क्या सेल्फ़-साइन्ड सर्टिफ़िकेट जैसी SSL एरर को नज़रअंदाज़ करने की कोई सेटिंग है?
नहीं — सर्टिफ़िकेट वेरिफ़िकेशन ब्राउज़र के अंदर ही होता है, किसी भी पेज की JavaScript (इस टूल समेत) तक रिक्वेस्ट पहुँचने से पहले ही, इसलिए इस टूल के पास इसे बायपास करने के लिए कोई सेटिंग हो ही नहीं सकती। अगर आप सेल्फ़-साइन्ड सर्टिफ़िकेट वाले किसी लोकल सर्वर को टेस्ट कर रहे हैं, तो उसका HTTPS URL एक बार नए ब्राउज़र टैब में सीधे खोलें और 'सुरक्षित नहीं है' वाली चेतावनी से सर्टिफ़िकेट स्वीकार कर लें। आपका ब्राउज़र वह अपवाद याद रख लेगा, और उसके बाद इस टूल से उसी URL पर भेजी गई रिक्वेस्ट सामान्य रूप से काम करेंगी।
क्या मैं कस्टम सेशन आईडी जैसी कोई कुकी वैल्यू खुद डाल सकता हूँ?
सीधे टाइप की गई वैल्यू के रूप में नहीं — ब्राउज़र सुरक्षा कारणों से JavaScript को Cookie हेडर सीधे सेट करने से रोकते हैं (यह उन चुनिंदा 'वर्जित' हेडर में से एक है), ठीक उसी तरह जैसा ऊपर सर्टिफ़िकेट वाले सवाल में बताया गया है। इसके बजाय आप Auth टैब में 'इस डोमेन के ब्राउज़र कुकीज़ शामिल करें' को चेक कर सकते हैं, जिससे ब्राउज़र में पहले से मौजूद उस डोमेन की कुकीज़ भेजी जाती हैं — जैसे अगर आप किसी दूसरे टैब में टारगेट साइट पर लॉग इन हैं। अगर आपको बहुत ही खास कुकी वैल्यू चाहिए, तो उस साइट को एक बार खोलकर ब्राउज़र के डेवलपर टूल (Application या Storage पैनल) से उस डोमेन के लिए कुकी सेट करें, फिर यहाँ चेकबॉक्स ऑन कर दें।