La modalità server
Restorm sa ospitare un server, non solo chiamarne uno. Si definisce una rotta e la sua risposta, si avvia l’ascolto e poi si punta un client su di essa — tipicamente il codice della propria applicazione — per verificare il modo in cui consuma il servizio.
È ciò che serve quando il servizio vero non esiste ancora, quando è
difficile fargli produrre la risposta che interessa (un errore 503,
un fault SOAP, uno stato gRPC preciso), oppure quando si vuole un insieme di dati
fisso per un test riproducibile.
Il principio è semplice ed è ciò che lo rende piacevole: ciò che si configura sul server è la risposta servita. Lo stato, gli header e il corpo che si inseriscono sono esattamente ciò che riceve il chiamante.
Protocolli compatibili
Section titled “Protocolli compatibili”| Server | Pagina |
|---|---|
| HTTP | Simulare un’API HTTP |
| GraphQL | Simulare un’API GraphQL |
| gRPC | Simulare un servizio gRPC |
| SOAP | Simulare un servizio SOAP |
| WebSocket, Socket.IO, MQTT | Simulare WebSocket, Socket.IO e MQTT |
| OData | Simulare un servizio OData |
Creare un server
Section titled “Creare un server”Clic destro su una cartella ▸ Aggiungi ▸ e poi la voce desiderata. Il menu propone otto server, ciascuno dei quali è un tipo di elemento distinto:
Server HTTP · Server GraphQL · Server gRPC · Server SOAP · Server WebSocket · Server Socket.IO · Server MQTT · Server OData
L’elemento creato porta un badge SRV nell’albero. Per un server HTTP, i
valori di partenza sono GET, localhost:8080/, stato 200.
Avviare e arrestare
Section titled “Avviare e arrestare”Nel pannello, il pulsante di invio è sostituito da un interruttore Listen ↔ Stop. Il pannello di risposta mostra lo stato in diretta: Not listening, oppure Listening — N request(s) served.
L’host è fissato a localhost: sono modificabili soltanto la porta e il
percorso. Un server di simulazione non è destinato a essere esposto in rete.
Il server si arresta con il pulsante Stop, con la chiusura del file oppure uscendo dall’applicazione.
Condivisione della porta
Section titled “Condivisione della porta”Restorm apre un solo socket per porta e smista in base alla natura della chiamata in ingresso: le richieste ordinarie verso le rotte HTTP, le richieste di passaggio verso WebSocket o Socket.IO.
In concreto: un server HTTP di simulazione e un server Socket.IO possono
ascoltare insieme su :8080. La porta viene liberata solo all’arresto della sua
ultima rotta.
Le variabili vengono risolte a caldo
Section titled “Le variabili vengono risolte a caldo”Gli header e il corpo serviti vengono risolti nel momento in cui la risposta viene servita, non all’avvio: modificare una variabile d’ambiente mentre il server è in ascolto cambia la risposta successiva. Si veda Variabili e ambienti.
In uno scenario
Section titled “In uno scenario”Le azioni Ascolto … / Chiusura … ospitano un server per la durata
dello scenario, con un output served che emette un evento per ogni chiamata
in ingresso. È ciò che permette di verificare un webhook da un capo all’altro in
un unico grafo. Si veda
Server ospitati.
Confronto con i server di simulazione ospitati
Section titled “Confronto con i server di simulazione ospitati”| Restorm | Server ospitati (tipo Postman Mock Servers) | |
|---|---|---|
| Dove gira | Sulla propria macchina | Presso il fornitore |
| Latenza | Nessun passaggio in rete | Un giro su Internet |
| Funziona offline | ✔ | ✘ |
| Sorgente della risposta | La richiesta stessa, modificabile | Un esempio salvato |
Template {{ }} | ✔, risolti a ogni chiamata | Limitati |
| Condivisione della porta | ✔ | Non applicabile |
| Riservatezza | Nulla esce dalla macchina | I dati transitano attraverso il servizio |