API रिक्वेस्ट बिल्डर

सर्वर सहायता API टेस्टिंग

रिक्वेस्ट विज़ुअली बनाएँ, उन्हें सुरक्षित relay से भेजें (या CORS की अनुमति हो तो सीधे ब्राउज़र से), स्टेटस, टाइमिंग, हेडर और फ़ॉर्मेट की गई बॉडी देखें, और रिक्वेस्ट को cURL या कोड के रूप में एक्सपोर्ट करें। संवेदनशील हेडर कभी स्टोर नहीं होते।

गोपनीयता: जहाँ संभव हो प्रोसेसिंग आपके ब्राउज़र में होती है। नेटवर्क जाँच मुत्क़न बैकएंड के माध्यम से की जाती है और संग्रहीत नहीं की जाती।

HTTP अनुरोध के हिस्से क्या हैं?

HTTP अनुरोध एक मेथड (GET, POST, PUT, PATCH, DELETE …) और लक्ष्य URL — पाथ और क्वेरी पैरामीटर — है, जिसके बाद हेडर और, डेटा ले जाने वाले मेथड के लिए, एक बॉडी होती है जिसका फ़ॉर्मेट Content-Type हेडर बताता है। RFC 9110 मेथड और उनके अर्थ परिभाषित करता है: GET और HEAD सुरक्षित हैं, PUT और DELETE आइडेम्पोटेंट, POST न यह न वह — और यही तय करता है कि अनुरोध दोबारा भेजा जा सकता है या नहीं। cURL कमांड लाइन वही अनुरोध लिखा हुआ रूप है, और बग रिपोर्ट में API कॉल दोहराने की साझा भाषा है।

गाइड पढ़ें: API टेस्टिंग क्या है? REST API कैसे टेस्ट करें

API रिक्वेस्ट बिल्डर कैसे इस्तेमाल करें

  1. method चुनें और URL डालें (query पैरामीटर Params टैब में जोड़े जा सकते हैं)।
  2. हेडर जोड़ें, auth टाइप चुनें या Body टैब में JSON बॉडी पेस्ट करें।
  3. Send दबाएँ। रिस्पॉन्स स्टेटस, समय, साइज़, फ़ॉर्मेट की गई बॉडी और हेडर के साथ दिखता है।
  4. अपनी टेस्ट सुइट के लिए रिक्वेस्ट को cURL या कोड के रूप में कॉपी करने हेतु Export पैनल खोलें।
  5. CORS की अनुमति देने वाले लोकल सर्वर को कॉल करते समय Settings में "Direct browser request" चालू करें।
डिफ़ॉल्ट रूप से relay आपकी जगह API को कॉल करता है, इसलिए CORS मायने नहीं रखता पर लोकल और प्राइवेट पते मना होते हैं; डायरेक्ट रिक्वेस्ट localhost तक तभी पहुँचती है जब टारगेट CORS की अनुमति दे।

  • relay से (डिफ़ॉल्ट)

    • ब्राउज़र यह पेज
    • Mutqan relay
    • टारगेट API
    1. 1 ब्राउज़र से Mutqan relay तक: आपकी रिक्वेस्ट method, URL, हेडर, बॉडी, टाइमआउट, रीडायरेक्ट फ़ॉलो
    2. 2 Mutqan relay आंतरिक रूप से: टारगेट जाँचता है प्राइवेट, loopback और link-local पते, आंतरिक होस्ट नाम और असामान्य पोर्ट कुछ भेजने से पहले ही मना कर दिए जाते हैं
    3. 3 Mutqan relay से टारगेट API तक: method, बॉडी और allowlist वाले हेडर Cookie, Host जैसे बाक़ी हेडर आगे नहीं जाते; X-Mutqan-Relay: 1 जुड़ता है
    4. 4 टारगेट API से Mutqan relay तक: रिस्पॉन्स जवाब कहने पर रीडायरेक्ट फ़ॉलो, हर hop दोबारा जाँचा जाता है
    5. 5 Mutqan relay से ब्राउज़र तक: स्टेटस, हेडर, बॉडी, साइज़, टाइमिंग जवाब बड़े रिस्पॉन्स relay काट देता है और चिह्नित करता है

    परिणाम: CORS की ज़रूरत नहीं; relay आपकी रिक्वेस्ट या रिस्पॉन्स कभी स्टोर नहीं करता।

  • Settings में "Direct browser request" चालू

    • ब्राउज़र यह पेज
    • टारगेट API जैसे localhost
    1. 1 ब्राउज़र से टारगेट API तक: ज़रूरत पर CORS preflight जैसे application/json वाला Content-Type, Authorization हेडर, या GET, HEAD, POST के अलावा कोई method OPTIONS
    2. 2 टारगेट API से ब्राउज़र तक: टारगेट को इसका जवाब देना ज़रूरी जवाब
    3. 3 ब्राउज़र से टारगेट API तक: आपकी रिक्वेस्ट, fetch से
    4. 4 टारगेट API से ब्राउज़र तक: रिस्पॉन्स जवाब पेज को दिखने वाले हेडर Access-Control-Expose-Headers से सीमित रहते हैं

    परिणाम: localhost और इंट्रानेट API तक पहुँचता है, जब तक वे CORS हेडर भेजें।

API रिक्वेस्ट बिल्डर की खूबियाँ

  • टैब वाले रिक्वेस्ट एडिटर में method, URL, query पैरामीटर, हेडर, बॉडी और auth (Bearer, Basic, API key)
  • डिफ़ॉल्ट रूप से CORS-मुक्त relay से भेजता है, या localhost और इंट्रानेट API के लिए सीधे ब्राउज़र से
  • रिस्पॉन्स पैनल: स्टेटस बैज, टाइमिंग, साइज़, pretty/raw/tree बॉडी व्यू और सॉर्ट होने वाली हेडर तालिका
  • रिक्वेस्ट को cURL, fetch, axios, Python, Java, C#, Go, PHP, Ruby या कच्चे HTTP के रूप में एक्सपोर्ट करें
  • JSON बॉडी फ़ॉर्मेटर, रिफ़्रेश के बाद भी रिक्वेस्ट सुरक्षित, भेजने के लिए Ctrl/⌘+Enter
  • संवेदनशील हेडर और क्रेडेंशियल कभी स्टोर नहीं किए जाते

API रिक्वेस्ट बिल्डर का उदाहरण

टेस्ट endpoint पर ऑर्डर POST करना

इनपुट:

POST https://httpbin.org/anything/orders
Content-Type: application/json

{ "customer": "cust_1029", "items": [{ "sku": "ABC-1234", "qty": 2 }] }

आउटपुट:

200 OK · 412 ms · 1.1 KB · application/json
{
  "json": { "customer": "cust_1029", "items": [ { "sku": "ABC-1234", "qty": 2 } ] },
  "method": "POST",
  …
}

API रिक्वेस्ट बिल्डर के बारे में अक्सर पूछे जाने वाले सवाल

क्या मेरी रिक्वेस्ट Mutqan के सर्वर से होकर जाती है?

डिफ़ॉल्ट रूप से हाँ: रिक्वेस्ट एक relay से भेजी जाती है ताकि CORS पाबंदियाँ उसे रोक न सकें, और relay आपकी रिक्वेस्ट या रिस्पॉन्स कभी स्टोर नहीं करता। endpoint को सीधे अपने ब्राउज़र से कॉल करने के लिए Settings में "Direct browser request" चालू करें — यह localhost और CORS की अनुमति देने वाले इंट्रानेट API के लिए उपयोगी है।

क्या मेरे टोकन या पासवर्ड सेव होते हैं?

नहीं। auth वैल्यू और संवेदनशील हेडर (Authorization, Cookie, API key) सिर्फ़ मौजूदा पेज की मेमोरी में रहते हैं। URL, पैरामीटर और बॉडी आपके ब्राउज़र सेशन में याद रहते हैं ताकि रिफ़्रेश करने पर आपका काम न छूटे।

http://localhost पर नेटवर्क एरर क्यों आता है?

सुरक्षा के कारण relay प्राइवेट, loopback और link-local पतों को मना कर देता है। "Direct browser request" चालू करें — जब तक लोकल सर्वर CORS हेडर भेजता है, आपका ब्राउज़र localhost तक पहुँच सकता है।

क्या मैं रिक्वेस्ट को कोड में एक्सपोर्ट कर सकता हूँ?

हाँ। भेजने के बाद Export पैनल cURL (bash, PowerShell, cmd), JavaScript fetch/axios, Python, Java, C#, Go, PHP, Ruby और कच्चा HTTP देता है।

क्या कोई साइज़ सीमा है?

1 MB तक की रिक्वेस्ट बॉडी relay से भेजी जाती है; इससे बड़े रिस्पॉन्स relay काट देता है और उन्हें ऐसा चिह्नित कर देता है।

तकनीकी नोट्स

relay endpoint method, बॉडी और रिक्वेस्ट हेडर की एक तय allowlist आगे भेजता है: Accept, Accept-Language, Accept-Encoding, Authorization, Content-Type, Cache-Control, If-None-Match, If-Modified-Since, Origin, Referer, User-Agent, SOAPAction, Access-Control-Request-* और X-Forwarded-* को छोड़कर सभी X-* हेडर। बाक़ी हेडर (जैसे Cookie, Host, Idempotency-Key या Prefer) आगे नहीं जाते; relay X-Mutqan-Relay: 1 जोड़ता है, और अगर आपने User-Agent न दिया हो तो अपना User-Agent भी। कहने पर यह रीडायरेक्ट फ़ॉलो करता है और हर hop को दोबारा जाँचता है, और स्टेटस, हेडर, बॉडी (relay की सीमा तक), साइज़ तथा टाइमिंग (कुल और time-to-first-byte) लौटाता है। प्राइवेट, loopback और link-local पते, आंतरिक होस्ट नाम और असामान्य पोर्ट कोई भी रिक्वेस्ट भेजे जाने से पहले ही मना कर दिए जाते हैं।

डायरेक्ट मोड में ब्राउज़र का fetch API इस्तेमाल होता है; GET, HEAD या POST के अलावा किसी method, form, multipart या text/plain के अलावा किसी Content-Type (जैसे application/json), या Authorization जैसे किसी ऐसे हेडर पर जो CORS-safelisted नहीं है, ब्राउज़र पहले CORS preflight भेजता है, और टारगेट को उसका जवाब देना ज़रूरी है। JavaScript को दिखने वाले रिस्पॉन्स हेडर टारगेट के Access-Control-Expose-Headers से सीमित रहते हैं।

संदर्भ

  • RFC 9110: HTTP SemanticsIETF · 2022HTTP मेथड, हेडर फ़ील्ड, स्टेटस कोड और कंटेंट निगोशिएशन के अर्थ, वायर वर्ज़न से स्वतंत्र।
  • HTTP headers — MDNMDN Web Docs (Mozilla)रिक्वेस्ट और रिस्पॉन्स हेडर का संदर्भ: सिंटैक्स, डायरेक्टिव और ब्राउज़र सपोर्ट।
  • RFC 7578: Returning Values from Forms: multipart/form-dataIETF · 2015फ़ाइल अपलोड और मिश्रित फ़ॉर्म सबमिशन के लिए इस्तेमाल होने वाली multipart/form-data एन्कोडिंग।