Simulare un’API HTTP
Clic destro su una cartella ▸ Aggiungi ▸ Server HTTP.
Configurare
Section titled “Configurare”Un server si configura con gli stessi campi di una richiesta — ed è proprio questo il vantaggio: il metodo e il percorso definiscono la rotta in ascolto, lo stato, gli header e il corpo definiscono la risposta servita.
| Campo | Ruolo |
|---|---|
| Metodo | Il metodo della rotta |
| Indirizzo | localhost:<port><path> — l’host è fissato |
| Stato di simulazione | Il codice restituito, 200 per impostazione predefinita |
| Header | Gli header della risposta |
| Corpo | Il corpo della risposta |

Il routing
Section titled “Il routing”Una rotta è una coppia metodo + percorso. L’appaiamento avviene sul percorso esatto, ignorando la stringa di query. Ogni chiamata che arriva sulla porta senza corrispondere a una rotta riceve un 404.
Due rotte entrano in collisione solo se condividono lo stesso metodo, lo stesso percorso e la stessa porta. È quindi possibile creare una richiesta server per rotta e avviarle tutte.
GET localhost:8080/clients → 200, elenco di clientiGET localhost:8080/clients/42 → 200, un clientePOST localhost:8080/clients → 201, header LocationGET localhost:8080/clients/999 → 404 (nessuna rotta: risposta predefinita)I template
Section titled “I template”Gli header e il corpo vengono risolti a ogni chiamata in ingresso. Un corpo
che contiene {{maintenant}} o {{compteur}} cambia quindi da una chiamata
all’altra se la variabile cambia.
Suggerimento: questo permette di pilotare il comportamento del server mentre è in esecuzione — basta cambiare il valore di una variabile d’ambiente e la chiamata successiva riceve una risposta diversa, senza riavviare.
Condivisione della porta
Section titled “Condivisione della porta”Un server HTTP di simulazione e un server WebSocket o Socket.IO possono ascoltare sulla stessa porta: Restorm smista le richieste ordinarie verso le rotte HTTP e le richieste di passaggio verso il server in tempo reale.
In uno scenario
Section titled “In uno scenario”L’azione Server HTTP ospita la rotta per la durata dello scenario ed emette un
evento served — che porta { request, response } — per ogni chiamata
ricevuta. È il modo per verificare un webhook:
Server HTTP ──connected──► Richiesta HTTP «attivare il webhook» └────────served──────► Assert su request.body poi ──► Chiusura server HTTPSi veda Server ospitati.