रिक्वेस्ट तुलना (Diff)

“इस बार क्यों सफल हुआ और पिछली बार क्यों विफल?” “एक ही endpoint के लिए, सफल request और विफल request के बीच ठीक कौन-सी लाइन अलग है?” दो requests / responses को साथ-साथ रखिए और जवाब तुरंत सामने आ जाता है। रुक-रुक कर आने वाली production समस्याओं की जाँच करने, अंतर को reproduce करने, और बदलावों को verify करने का यह सबसे तेज़ तरीका है।

---

1. इस्तेमाल कैसे करें: दो चरणों में पूरा

1. किसी भी traffic पर right-click करें और “Mark as compare A” चुनें।
2. किसी दूसरे traffic पर right-click करें और “Compare with A” चुनें।

एक साथ-साथ तुलना विंडो तुरंत खुल जाती है, जो दोनों के बीच हर अंतर को लाइन-दर-लाइन चिह्नित करती है।

---

2. क्या देखें: requests और responses दोनों की तुलना हो सकती है

विंडो के ऊपर एक टैप से request या response की तुलना के बीच स्विच किया जा सकता है। दोनों तरफ A और B होते हैं, हर एक के साथ एक लेबल (method · host · status), ताकि आप एक नज़र में देख सकें कि आप किन दो चीज़ों की तुलना कर रहे हैं। यह तुलना पूरे message को कवर करती है:

• Start line: request line (method / address / protocol) या response line (protocol / status code)
• सारे request headers / response headers
• Request body / response body (स्वचालित रूप से beautify किया गया, फिर लाइन-दर-लाइन compare किया गया, JSON, XML, और forms सभी आसानी से पढ़े जा सकते हैं)

---

3. एक नज़र में अंतर

• पहले beautify, फिर लाइन-दर-लाइन diff: JSON, XML, और forms को पहले format किया जाता है और फिर लाइन-दर-लाइन compare किया जाता है, ताकि जो fields वाकई बदले हैं वे एक नज़र में सामने आ जाएँ, बिना line breaks और indentation जैसे format noise में दबे।
• लाइन-दर-लाइन रंग कोडिंग: additions (+), deletions (−), और changes (~) को अलग-अलग हाइलाइट किया जाता है, A साइड को लाल और B साइड को हरे रंग से चिह्नित किया जाता है, और बदली हुई लाइनों को साथ-साथ दिखाया जाता है।
• अंतर की गिनती: सबसे ऊपर “added / deleted / changed” लाइनों की संख्या का सारांश दिया जाता है, ताकि आपको पैमाने का अंदाज़ा हो।
• जब दोनों एक जैसे हों तो बता देता है: जब दोनों मेल खाते हैं, तो यह साफ़ तौर पर “identical” दिखाता है, ताकि आपको खुद लाइन-दर-लाइन जाँचना न पड़े; जब किसी एक तरफ कोई content न हो या अभी तक डिक्रिप्ट न हुआ हो, तो यह सीधे बता देता है, बजाय आपको इंतज़ार में रखने के।
• लाइन नंबर के साथ: हर तरफ की अपनी लाइन नंबरिंग होती है ताकि सटीक स्थान पता किया जा सके।

---

4. यह कहाँ सबसे ज़्यादा उपयोगी है: sessions और sources के आर-पार तुलना

जिन दो records की तुलना की जा रही है, उनका एक ही capture session से होना ज़रूरी नहीं, न ही उन्हें एक ही समय पर कैप्चर किया गया होना ज़रूरी है; जब तक आपने उन्हें interface में देखा है, आप उन्हें तुलना के लिए ला सकते हैं:

• सफलता बनाम विफलता: एक सफल request और एक विफल request को साथ रखें और तुरंत देखें कि कौन-सा header, कौन-सा parameter, या body का कौन-सा हिस्सा अलग है।
• खुद बनाया गया बनाम असली: Request Composer में replay / send करके फिर कैप्चर किए गए request की तुलना पहले कैप्चर किए गए असली request से करें, ताकि यह सत्यापित हो सके कि “क्या मैंने इसे सही बनाया” और “क्या signature लगातार एक जैसे तरीके से बन रहा है।”
• बदलाव से पहले और बाद में: server / client में बदलाव करने के बाद, पुराने और नए requests की तुलना करें ताकि यह पुष्टि हो सके कि बदलाव लागू हुआ या नहीं और इसके कोई side effects तो नहीं हैं।
• environments के आर-पार: एक ही endpoint के test environment और production environment में मिले returns को साथ-साथ देखें ताकि configuration या data के अंतर को जल्दी पता लगाया जा सके।

यही वह जगह भी है जहाँ यह किसी अकेले request का निरीक्षण करने से कहीं ज़्यादा शक्तिशाली है: अंतर तुलना के ज़रिए सामने आते हैं, न कि याददाश्त और आँखों पर निर्भर रहकर। सामान्य टूल्स अक्सर केवल एक ही session के भीतर, आँखों से, एक-एक करके तुलना कर पाते हैं।

---

5. सामान्य परिदृश्य

• रुक-रुक कर आने वाली विफलताओं की जाँच: सफल request बनाम विफल request, ताकि अलग field का पता लगाया जा सके।
• Integration alignment: client ने वास्तव में जो request भेजी बनाम API documentation / अपेक्षित request।
• Regression verification: बदलाव से पहले और बाद में एक ही request / response में अंतर की पुष्टि करना।
• Signature debugging: खुद बनाई गई signed request बनाम असली request, यह verify करना कि हर हिस्सा consistent है या नहीं।

---

वापस Proxy Capture पर · संबंधित: Request Composing and Replay