कंपोज़ और रीप्ले (Composer)
कैप्चरिंग सिर्फ़ “देखने” के बारे में नहीं है। Trace Eagle का रिक्वेस्ट कंपोज़र (Composer) “असली कैप्चर की गई रिक्वेस्ट” और “मैन्युअल तरीके से बनाना और डीबग करना” दोनों को एक ही जगह लाता है: किसी भी कैप्चर की गई रिक्वेस्ट को ज्यों का त्यों दोबारा भेजा जा सकता है, या पैरामीटर बदलने के बाद दोबारा भेजा जा सकता है; आप शुरू से भी एक रिक्वेस्ट बना कर भेज सकते हैं। अब कैप्चर टूल और अलग API-डीबगिंग टूल के बीच बार-बार स्विच करने की ज़रूरत नहीं है।
1. दो एंट्री पॉइंट
Section titled “1. दो एंट्री पॉइंट”- रीसेंड / एडिट करके रीप्ले: ट्रैफ़िक लिस्ट में राइट-क्लिक करें, या डिटेल पैनल में “Edit and resend” पर क्लिक करें, इससे यह कैप्चर की गई रिक्वेस्ट ज्यों की त्यों composer में लोड हो जाती है। एड्रेस कैप्चर के समय के प्रोटोकॉल / होस्ट / पोर्ट से रिस्टोर होता है, अप्रासंगिक कनेक्शन हेडर हटा दिए जाते हैं, और बॉडी व उसका टाइप कंटेंट से डिटेक्ट हो जाता है, यह सब अपने आप होता है। कुछ पैरामीटर बदलें और दोबारा भेज दें।
- शुरू से बनाना: composer में सीधे हाथ से एक नई रिक्वेस्ट असेंबल करें।
दोनों एंट्री पॉइंट एक ही सेंड चैनल का इस्तेमाल करते हैं, और नतीजे एक अलग Composer सेशन टैब में रिकॉर्ड होते हैं (पूरी हिस्ट्री सुरक्षित रहती है), जहाँ इन्हें, किसी कैप्चर की गई रिक्वेस्ट की तरह, देखा जा सकता है, फिर से एडिट किया जा सकता है, और कंपेयर किया जा सकता है।
2. हाथ से रिक्वेस्ट बनाना
Section titled “2. हाथ से रिक्वेस्ट बनाना”- रिक्वेस्ट लाइन: मेथड (GET / POST / PUT / DELETE / PATCH / HEAD / OPTIONS) + URL।
- पैरामीटर टेबल: क्वेरी पैरामीटर एक टेबल में पंक्ति दर पंक्ति मैनेज होते हैं, URL से अलग रखे जाते हैं और सेंड के समय ही असेंबल होते हैं, यानी इनके अंदर मौजूद डायनामिक प्लेसहोल्डर समय से पहले एनकोडिंग से खराब नहीं होते।
- हेडर टेबल: किसी भी हेडर पंक्ति को जोड़ें, हटाएं, या एडिट करें।
- ऑथ हेल्पर: None / Bearer Token / Basic (यूज़रनेम + पासवर्ड, base64 अपने आप); यह तभी असर करता है जब आपने खुद Authorization हेडर न लिखा हो।
- बॉडी: none / JSON / form (form-urlencoded) / raw text; JSON या form चुनने पर मैचिंग Content-Type अपने आप जुड़ जाता है।
3. डायनामिक वैल्यूज़: साइन्ड / एन्क्रिप्टेड प्राइवेट API हैंडल करना
Section titled “3. डायनामिक वैल्यूज़: साइन्ड / एन्क्रिप्टेड प्राइवेट API हैंडल करना”किसी भी फ़ील्ड में ${...} डायनामिक वैल्यूज़ हो सकते हैं, जिन्हें भेजने से पहले इंजन द्वारा एवैल्यूएट किया जाता है। signature / timestamp / nonce ले जाने वाली प्राइवेट API डीबग करते समय यह बहुत काम आता है:
| डायनामिक वैल्यू | उद्देश्य |
|---|---|
${uuid} / ${randomUUID} |
रैंडम UUID |
${timestamp} |
सेकंड में Unix timestamp |
${timestampMs} / ${now} |
मिलीसेकंड में Unix timestamp |
${random} |
16-अंकों का रैंडम hex |
${randomInt:min,max} |
एक रेंज में रैंडम इंटीजर |
${base64:} / ${base64url:} / ${base64decode:} |
Base64 एनकोड / डिकोड |
${md5:} / ${sha1:} / ${sha256:} |
Hash |
${hmacSha256:key,msg} / ${hmacSha256Base64:key,msg} / ${hmacSha1:key,msg} |
HMAC signature |
${urlEncode:} / ${upper:} / ${lower:} |
URL एनकोड / केस बदलना |
- नेस्टिंग सपोर्टेड: उदाहरण के लिए
${hmacSha256:${secret},${body}}, पहले वेरिएबल रिज़ॉल्व होता है, फिर signature कैलकुलेट होता है। - जो रिज़ॉल्व नहीं हो पाता वह ज्यों का त्यों रहता है, इसलिए आप एक नज़र में देख सकते हैं कि कौन सा वेरिएबल एवैल्यूएट नहीं हुआ, जबकि सामान्य टूल्स अक्सर किसी अपरिभाषित वेरिएबल पर एरर दे देते हैं या खाली वैल्यू भेज देते हैं।
4. Environments और Collections
Section titled “4. Environments और Collections”- Environment variables:
${name}को environment variables में एक्सट्रैक्ट करें, और एक क्लिक में कई environments (जैसे “dev / test / prod”) के बीच स्विच करें; variables एक-दूसरे को रेफ़र कर सकते हैं और चेन में एक्सपैंड हो सकते हैं। - Collections: बार-बार इस्तेमाल होने वाली रिक्वेस्ट को नामित फ़ोल्डर्स में ग्रुप करें, मौजूदा रिक्वेस्ट को कभी भी सेव करें, और जब चाहें उसे दोबारा इस्तेमाल के लिए लोड करें।
- वर्कस्पेस की ऑटोमैटिक सेविंग: collections + environments अपने आप एक प्लेन-टेक्स्ट, वर्ज़न-कंट्रोल करने लायक फ़ाइल के रूप में सेव होते हैं जिसे diff किया जा सकता है और रिव्यू किया जा सकता है, जिससे टीम में शेयर करना और हिस्ट्री ट्रेस करना आसान हो जाता है।
5. Import और Code Generation
Section titled “5. Import और Code Generation”- cURL import: एक cURL कमांड पेस्ट करें और उसे एडिट करने लायक रिक्वेस्ट में पार्स करें (सामान्य पैरामीटर जैसे
-X / -H / -d / --data-* / -u / -b / -A / -eसपोर्टेड हैं, कोट हैंडलिंग सहित, और बॉडी होने पर इसे अपने आप POST मान लिया जाता है)। - Collection फ़ाइल import: बाहरी API collection फ़ाइलें import करें (raw body मुख्य फ़ोकस है; ग्रुप्स को एक ही collection में फ़्लैटन कर दिया जाता है)।
- Code generation: मौजूदा रिक्वेस्ट को एक क्लिक में cURL / Python / JavaScript(fetch) / Go / OkHttp कोड स्निपेट में एक्सपोर्ट करें, स्क्रिप्ट लिखने, प्रोजेक्ट में डालने, या किसी सहकर्मी के साथ शेयर करने के लिए सुविधाजनक।
6. Faithful sending: reproduction को असली path के करीब रखना
Section titled “6. Faithful sending: reproduction को असली path के करीब रखना”रीप्ले की असली वैल्यू इसी में है कि “reproduce की गई रिक्वेस्ट असली environment से मेल खाए”। composer की settings में, भेजते समय कैप्चर सेशन जैसी ही नेटवर्क विशेषताएं बनाए रखी जा सकती हैं, जिससे नतीजे ज़्यादा भरोसेमंद बनते हैं:
- अपस्ट्रीम प्रॉक्सी: अपस्ट्रीम प्रॉक्सी (http / socks5) से भेजें, रीप्ले की गई रिक्वेस्ट को कंपनी प्रॉक्सी, जंप होस्ट, या किसी अन्य सेकेंडरी प्रॉक्सी की तरफ़ रूट करें।
- रिक्वेस्ट characteristics fidelity (browser profile): रीप्ले की गई रिक्वेस्ट की नेटवर्क विशेषताओं को किसी स्टैंडर्ड क्लाइंट (जैसे कोई आम ब्राउज़र) जैसा रिस्टोर करें, ताकि reproduce की गई रिक्वेस्ट असली path से मेल खाती रहे।
- कस्टम DNS: तय करें कि डोमेन को कौन-सा DNS resolve करे, ताकि poisoning से बचा जा सके या कोई तय रूट लिया जा सके।
भेजने से पहले, सभी ${...} डायनामिक वैल्यूज़ पहले लोकली एवैल्यूएट हो जाती हैं, इसलिए आप हमेशा ठीक-ठीक देख सकते हैं कि असल में क्या भेजा जाएगा। हर सेंड एक अलग Composer सेशन से होकर गुज़रता है, जो कैप्चर सेशन से आइसोलेटेड है; नतीजे स्टेटस कोड, प्रोटोकॉल, और लगा हुआ समय इनलाइन दिखाते हैं, और सेशन में एक Flow के रूप में रिकॉर्ड होते हैं, इसलिए इन्हें भी, किसी कैप्चर की गई रिक्वेस्ट की तरह, दोबारा देखा जा सकता है, फिर से एडिट किया जा सकता है, और कंपेयर किया जा सकता है।
7. Request Comparison (Diff) के साथ जोड़ी
Section titled “7. Request Comparison (Diff) के साथ जोड़ी”एक compose / replay की गई रिक्वेस्ट को हिस्ट्री की किसी असली कैप्चर की गई रिक्वेस्ट के साथ लाइन दर लाइन, साइड बाय साइड कंपेयर किया जा सकता है, जिससे तुरंत पता चलता है कि “उसी endpoint के लिए इस बार और पिछली बार में असल में क्या फ़र्क़ है”, जो signature, parameter, और response के अंतर को ट्रबलशूट करने में खासतौर पर कारगर है। देखें Request Comparison।
वापस जाएं Proxy Capture · संबंधित: Rewrite Rules and Breakpoints · Request Comparison