उपयोग का मामला

अपने API को तोड़ें जानबूझकर।

किसी भी क्लाइंट को प्रॉक्सी पर पॉइंट करें, फिर एक 500 मॉक करें, किसी रिक्वेस्ट को बीच में पॉज़ करें, या ठीक वही हुआ उसे HAR के रूप में एक्सपोर्ट करें जिसे आप किसी टीम साथी को दे सकते हैं।

An Android phone, a browser and a backend server stream traffic into a central proxy hexagon on port 8888; one stream passes a block-and-script rule gate and comes out transformed, then one live stream flows on into a dashboard feed with green status codes. A globe marks upstream proxy routing. android browser server {} rules :8888 upstream live 200 201 200

समस्या

एक API बग को दोबारा उत्पन्न करने का मतलब है बैकएंड को नकली बनाना

एक धीमा एंडपॉइंट, एक विकृत एरर बॉडी, दो कॉल्स के बीच एक रेस कंडीशन — इनमें से किसी को भी असली सर्वर से मांग पर उत्पन्न करना आसान नहीं है।

बैकएंड और फुल-स्टैक इंजीनियरों के लिए जो एक API क्लाइंट — मोबाइल ऐप, फ्रंटएंड, CLI, CI जॉब — बना या टेस्ट कर रहे हैं और जिन्हें वायर पर सटीक बाइट्स देखने और नियंत्रित करने की ज़रूरत है, न कि केवल SDK द्वारा दिया गया रिस्पॉन्स।

Busymate का proxy-server आपके क्लाइंट और असली API के बीच बैठता है। हर रिक्वेस्ट लाइव कैप्चर होती है, और वही ब्लॉक/मॉक/ड्रॉप रूल इंजन जो iOS और Chrome कैप्चर पर चलता है यहां भी चलता है — इसलिए आप बैकएंड को छुए बिना किसी असली रिक्वेस्ट का जवाब एक तैयार रिस्पॉन्स से दे सकते हैं, या उसे पूरी तरह ड्रॉप कर सकते हैं।

यह कैसे हल करता है

एक PAC URL, इसके पीछे पूरा टूलकिट

कोई SDK नहीं, इंस्टॉल करने के लिए कोई एजेंट नहीं — कोई भी क्लाइंट जिसे प्रॉक्सी पर पॉइंट किया जा सके, पहले से ही इंटीग्रेटेड है।

वायर पर मॉक, ब्लॉक या ड्रॉप करें

किसी मेल खाती रिक्वेस्ट का जवाब अपने स्टेटस, हेडर और बॉडी से दें — या उसे ड्रॉप करें — उन नियमों का उपयोग करके जो खुद प्रॉक्सी में इनलाइन चलते हैं, इससे पहले कि रिक्वेस्ट असली API तक पहुंचे।

ब्रेकपॉइंट, संपादित करें, फिर से भेजें

किसी रिक्वेस्ट को बीच में पॉज़ करें, कच्चे HTTP को हाथ से एडिट करें, फिर जारी रखें या फिर से भेजें — बिना एक भी टेस्ट कोड लाइन लिखे रेस कंडीशन या विकृत पेलोड को दोबारा उत्पन्न करें।

HAR एक्सपोर्ट करें, या REST से एक्सेस करें

किसी टीम साथी या बग रिपोर्ट के लिए ठीक उसी एक्सचेंज को HAR फ़ाइल के रूप में एक्सपोर्ट करें, या उसी कैप्चर किए गए डेटा तक सीधे PostgREST-आधारित REST API से पहुंचें — दोनों ही तरीकों में किसी SDK की ज़रूरत नहीं।

शामिल सतहें
  • Proxy
  • Dashboard
  • REST
  • MCP

वॉकथ्रू

एक अस्थिर क्लाइंट से एक पुनरुत्पादनीय बग रिपोर्ट तक

किसी भी छोर पर कोई कोड बदलाव नहीं।

  1. 01

    क्लाइंट को प्रॉक्सी पर पॉइंट करें

    क्लाइंट — एक फ़ोन, एक ब्राउज़र, एक बैकएंड सर्विस, एक CI जॉब — को एक PAC ऑटो-कॉन्फ़िग URL से कॉन्फ़िगर करें। ट्रैफ़िक तुरंत स्ट्रीम होना शुरू हो जाता है।

  2. 02

    विफलता को दोबारा उत्पन्न करें

    एंडपॉइंट को मॉक करें ताकि वह आपको चाहिए टूटा हुआ रिस्पॉन्स दे, या एक ब्रेकपॉइंट सेट करें और असली रिक्वेस्ट या रिस्पॉन्स को आगे बढ़ने से पहले हाथ से एडिट करें।

  3. 03

    परिणाम को एक्सपोर्ट या क्वेरी करें

    किसी बग रिपोर्ट में अटैच करने के लिए एक्सचेंज को HAR के रूप में एक्सपोर्ट करें, या उन्हीं कैप्चर की गई एंट्रीज़ को अपने टेस्ट सूट से REST API के ज़रिए खींचें।

प्रॉक्सी पर

यह कैसे काम करता है: वायर पर

आपके क्लाइंट और असली API के बीच एक प्रॉक्सी बैठता है; नियम उसके अंदर चलते हैं।

  1. 01

    क्लाइंट को अपने प्रॉक्सी की ओर मोड़ें

    हर डिवाइस की अपनी प्रॉक्सी पहचान और एक प्रॉक्सी ऑटो-कॉन्फ़िग URL होता है। वह URL फ़ोन की Wi-Fi सेटिंग, ब्राउज़र प्रोफ़ाइल या उस HTTP-प्रॉक्सी वेरिएबल में पेस्ट करें जिसे कोई बैकएंड या CI जॉब पढ़ता है, और उसके अनुरोध तुरंत डैशबोर्ड फ़ीड में आने लगते हैं।

  2. 02

    नियम लिखें, या अनुरोध रोकें

    कोई एंट्री खोलें और चुनें कि अगली बार क्या हो: अनुरोध का जवाब अपने स्टेटस, हेडर और बॉडी से दें, उसे गिरा दें, या ब्रेकपॉइंट लगाएँ ताकि अगला मेल खाता अनुरोध बीच में रुक जाए। कच्चे अनुरोध या रिस्पॉन्स को हाथ से संपादित करें, फिर जारी रखें या दोबारा भेजें।

  3. 03

    आदान-प्रदान किसी और को सौंपें

    बग रिपोर्ट के लिए अनुरोध और रिस्पॉन्स को HAR फ़ाइल के रूप में निर्यात करें, या वही कैप्चर की गई एंट्रियाँ टेस्ट सूट से REST API के ज़रिए पढ़ें। दोनों में वायर पर गए सटीक बाइट होते हैं, किसी SDK की व्याख्या नहीं।

सामान्य प्रश्न

क्लाइंट मोड़ने से पहले, आम सवाल

क्या मेरे क्लाइंट को SDK या कोड बदलाव चाहिए?

नहीं। जो कुछ भी HTTP प्रॉक्सी की ओर मोड़ा जा सकता है वह पहले से एकीकृत है — फ़ोन, ब्राउज़र, बैकएंड सेवाएँ, CI जॉब। प्रॉक्सी कैप्चर और नियम संभालता है; आपका क्लाइंट उसी से बात करता रहता है जिसे वह असली API समझता है।

क्या मैं सिर्फ़ एक एंडपॉइंट मॉक करके बाकी असली रख सकता हूँ?

हाँ। नियम होस्ट और पाथ पैटर्न पर मेल खाते हैं, इसलिए एक एंडपॉइंट तैयार 500 लौटा सकता है जबकि बाकी सभी अनुरोध असली बैकएंड तक अछूते जाते हैं।

क्या ब्रेकपॉइंट बाकी ट्रैफ़िक रोकता है?

नहीं। सिर्फ़ मेल खाता अनुरोध रुकता है; बाकी सब बहता रहता है। तैयार होने पर जारी रखें, संपादित करें या दोबारा भेजें, और क्लाइंट को नतीजा ऐसे दिखता है मानो सर्वर ने जवाब दिया हो।

क्या मेरे टेस्ट कैप्चर किया गया ट्रैफ़िक पढ़ सकते हैं?

हाँ। कैप्चर की गई एंट्रियाँ एक सादे REST API के ज़रिए उपलब्ध हैं, इसलिए इंटीग्रेशन टेस्ट मॉक की अपेक्षाओं के बजाय यह जाँच सकता है कि क्लाइंट ने असल में क्या भेजा।

बैकएंड को नकली बनाना बंद करें — असली वायर को नियंत्रित करें

अपने पहले क्लाइंट को प्रॉक्सी पर पॉइंट करें और मिनटों में अपनी पहली रिक्वेस्ट को मॉक, ब्रेक या फिर से भेजें।

Ask your mate