Salta ai contenuti

Cronologia delle richieste

Ogni esecuzione di una richiesta viene registrata, qualunque sia il protocollo: HTTP, GraphQL, gRPC, SOAP, WebSocket, JSON-RPC, tRPC, SSE, AMQP, Redis, STOMP, Kafka, OData.

Il pulsante a forma di orologio nella smartbar — tooltip Cronologia delle richieste. Apre la finestra modale Cronologia delle risposte, limitata alla scheda corrente: l’albero laterale e le altre schede restano utilizzabili durante la consultazione.

La finestra modale «Cronologia delle risposte»: a sinistra l’elenco con marca temporale delle risposte passate, a destra il dettaglio della risposta selezionata con le sue sotto-schede Risposta / Info / Grafo

Ogni voce riporta:

  • la propria data, in formato US o ISO secondo l’impostazione Comportamento ▸ Formato data/ora;
  • una pastiglia di stato a tre stati: verde (successo), arancione (reindirizzamento), rosso (fallimento);
  • un’icona a forma di puntina se la voce è appuntata.

La resa è identica a quella della scheda in diretta: informazioni, header, corpo nel visualizzatore JSON richiudibile — più una cosa che la scheda live non mostra: il corpo della richiesta effettivamente inviato, riformattato (JSON indentato, XML, chiave=valore per un form, oppure il percorso del file inviato).

È ciò che permette di rispondere a «che cosa avevo inviato esattamente, la volta in cui funzionava?».

Restorm conserva le ultime dieci voci non appuntate per richiesta. Oltre a queste, le più vecchie vengono eliminate.

Il menu contestuale di una voce propone Appunta / Rimuovi puntina: una voce appuntata sopravvive indefinitamente. Conviene appuntare la risposta di riferimento di un caso interessante, così non se ne andrà con i tentativi successivi.

In un archivio collocato accanto al progetto: <project>.responses.zip. Contiene la cronologia per richiesta e la cronologia di esecuzione degli scenari.

Poiché questo archivio può contenere dati di risposta di grandi dimensioni, è fuori dal file di progetto — conviene aggiungerlo al proprio .gitignore.

I token prodotti dalle richieste di autenticazione vengono depurati nei corpi e negli header archiviati. Lo strumento MCP get_response_history passa dallo stesso servizio: un agente IA non può recuperare un token attraverso la cronologia.