Caso d'uso

Rompi la tua API di proposito.

Punta qualsiasi client al proxy, poi simula un 500, metti in pausa una richiesta a metà volo, o esporta esattamente ciò che è successo come HAR da consegnare a un collega.

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

Il problema

Riprodurre un bug dell'API significa simulare il backend

Un endpoint lento, un corpo di errore malformato, una race condition tra due chiamate — niente di tutto ciò è facile da innescare a comando da un server reale.

Per ingegneri backend e full-stack che costruiscono o testano un client API — un'app mobile, un frontend, una CLI, un job CI — e devono vedere e controllare i byte esatti sul filo, non solo la risposta restituita da un SDK.

Il proxy-server di Busymate si trova tra il tuo client e l'API reale. Ogni richiesta viene catturata live, e lo stesso motore di regole blocca/simula/elimina che gira su iOS e sulla cattura Chrome gira anche qui — così puoi rispondere a una richiesta reale con una preconfezionata, o eliminarla del tutto, senza toccare il backend.

Come lo risolve

Un URL PAC, tutto il toolkit dietro

Nessun SDK, nessun agente da installare — qualsiasi client che possa puntare a un proxy è già integrato.

Simula, blocca o elimina sul filo

Rispondi a una richiesta corrispondente con il tuo stato, header e corpo — o eliminala — usando regole che girano in linea nel proxy stesso, prima che la richiesta raggiunga mai l'API reale.

Breakpoint, modifica, reinvia

Metti in pausa una richiesta a metà volo, modifica l'HTTP grezzo a mano, poi continua o reinviala — riproduci una race condition o un payload malformato senza scrivere una riga di codice di test.

Esporta in HAR, o accedi via REST

Esporta lo scambio esatto come file HAR per un collega o un bug report, oppure raggiungi gli stessi dati catturati tramite la semplice API REST basata su PostgREST — nessun SDK richiesto in entrambi i casi.

Superfici coinvolte
  • Proxy
  • Dashboard
  • REST
  • MCP

Procedura guidata

Da un client instabile a un bug report riproducibile

Nessuna modifica al codice da entrambi i lati.

  1. 01

    Punta il client al proxy

    Configura il client — un telefono, un browser, un servizio backend, un job CI — dall'unico URL di auto-configurazione PAC. Il traffico inizia a fluire immediatamente.

  2. 02

    Riproduci il fallimento

    Simula l'endpoint in modo che restituisca la risposta rotta di cui hai bisogno, oppure imposta un breakpoint e modifica a mano la richiesta o risposta reale prima che prosegua.

  3. 03

    Esporta o interroga il risultato

    Esporta lo scambio come HAR da allegare a un bug report, oppure recupera le stesse voci catturate dalla tua suite di test tramite l'API REST.

Sul proxy

Come funziona sul filo

Un proxy si mette tra il tuo client e l'API reale; le regole girano al suo interno.

  1. 01

    Punta un client al tuo proxy

    Ogni dispositivo ha la propria identità proxy e un URL di configurazione automatica. Incolla quell'URL nelle impostazioni Wi-Fi di un telefono, in un profilo del browser o nella variabile proxy HTTP che legge un backend o un job di CI, e le sue richieste iniziano subito a comparire nel feed della dashboard.

  2. 02

    Scrivi una regola, o metti in pausa la richiesta

    Apri una voce e scegli cosa deve succedere la prossima volta: rispondere alla richiesta con stato, header e corpo tuoi, scartarla, oppure impostare un breakpoint così che la prossima richiesta corrispondente si fermi a metà strada. Modifica a mano la richiesta o la risposta grezza, poi continua o reinviala.

  3. 03

    Passa lo scambio a qualcun altro

    Esporta richiesta e risposta come file HAR per una segnalazione di bug, oppure leggi le stesse voci catturate da una suite di test tramite l'API REST. Entrambi contengono i byte esatti passati sul filo, non l'interpretazione di un SDK.

FAQ

Prima di puntare un client, le solite domande

Il mio client ha bisogno di un SDK o di modifiche al codice?

No. Tutto ciò che può essere puntato a un proxy HTTP è già integrato: telefoni, browser, servizi backend, job di CI. Il proxy gestisce cattura e regole; il tuo client continua a parlare con quella che crede essere l'API reale.

Posso simulare un solo endpoint e lasciare il resto reale?

Sì. Le regole corrispondono a pattern di host e percorso, quindi un endpoint può restituire un 500 preconfezionato mentre tutte le altre richieste passano intatte al backend reale.

Un breakpoint blocca il resto del traffico?

No. Si ferma solo la richiesta corrispondente; tutto il resto continua a scorrere. Continua, modifica o reinvia quando sei pronto, e il client vede il risultato come se il server avesse risposto.

I miei test possono leggere il traffico catturato?

Sì. Le voci catturate sono disponibili tramite una semplice API REST, così un test di integrazione può verificare cosa ha davvero inviato il client invece di cosa si aspettava un mock.

Smetti di simulare il backend — controlla il filo reale

Punta il tuo primo client al proxy e simula, rompi o reinvia la tua prima richiesta in pochi minuti.

Ask your mate