Le mode serveur
Restorm sait héberger un serveur, et pas seulement en appeler un. Vous définissez une route et sa réponse, vous démarrez l’écoute, puis vous pointez un client dessus — typiquement le code de votre application — pour tester la façon dont il consomme le service.
C’est ce qu’il faut quand le vrai service n’existe pas encore, quand il est
difficile de lui faire produire la réponse qui vous intéresse (une erreur 503,
une faute SOAP, un statut gRPC précis), ou quand vous voulez un jeu de données
figé pour un test reproductible.
Le principe est simple et c’est ce qui le rend agréable : ce que vous configurez sur le serveur est la réponse servie. Le statut, les en-têtes et le corps que vous saisissez sont exactement ce que reçoit l’appelant.
Protocoles compatibles
Section titled “Protocoles compatibles”| Serveur | Page |
|---|---|
| HTTP | Simuler une API HTTP |
| GraphQL | Simuler une API GraphQL |
| gRPC | Simuler un service gRPC |
| SOAP | Simuler un service SOAP |
| WebSocket, Socket.IO, MQTT | Simuler WebSocket, Socket.IO et MQTT |
| OData | Simuler un service OData |
Créer un serveur
Section titled “Créer un serveur”Clic droit sur un dossier ▸ Ajouter ▸ puis l’entrée voulue. Le menu propose huit serveurs, chacun étant un type d’élément distinct :
Serveur HTTP · Serveur GraphQL · Serveur gRPC · Serveur SOAP · Serveur WebSocket · Serveur Socket.IO · Serveur MQTT · Serveur OData
L’élément créé porte un badge SRV dans l’arbre. Pour un serveur HTTP, les
valeurs de départ sont GET, localhost:8080/, statut 200.
Démarrer et arrêter
Section titled “Démarrer et arrêter”Dans le panneau, le bouton d’envoi est remplacé par une bascule Listen ↔ Stop. Le panneau de réponse affiche l’état en direct : Not listening, ou Listening — N request(s) served.
L’hôte est figé à localhost : seuls le port et le chemin sont éditables.
Un serveur de simulation n’a pas vocation à être exposé au réseau.
Le serveur s’arrête par le bouton Stop, par la fermeture du fichier, ou en quittant l’application.
Partage de port
Section titled “Partage de port”Restorm n’ouvre qu’une seule socket par port et aiguille selon la nature de l’appel entrant : les requêtes ordinaires vers les routes HTTP, les demandes de bascule vers WebSocket ou Socket.IO.
Concrètement : un serveur HTTP de simulation et un serveur Socket.IO peuvent
écouter ensemble sur :8080. Le port n’est libéré qu’à l’arrêt de sa
dernière route.
Les variables sont résolues à chaud
Section titled “Les variables sont résolues à chaud”Les en-têtes et le corps servis sont résolus au moment de servir, pas au démarrage : modifier une variable d’environnement pendant que le serveur écoute change la réponse suivante. Voir Variables et environnements.
Dans un scénario
Section titled “Dans un scénario”Les actions Écoute … / Fermeture … hébergent un serveur pour la durée
du scénario, avec une sortie served qui émet un événement par appel
entrant. C’est ce qui permet de tester un webhook de bout en bout dans un
seul graphe. Voir
Serveurs hébergés.
Comparaison avec les serveurs de simulation hébergés
Section titled “Comparaison avec les serveurs de simulation hébergés”| Restorm | Serveurs hébergés (type Postman Mock Servers) | |
|---|---|---|
| Où ça tourne | Sur votre machine | Chez le fournisseur |
| Latence | Aucun aller-retour réseau | Un aller-retour Internet |
| Fonctionne hors ligne | ✔ | ✘ |
| Source de la réponse | La requête elle-même, éditable | Un exemple enregistré |
Gabarits {{ }} | ✔, résolus à chaque appel | Limités |
| Partage de port | ✔ | Sans objet |
| Confidentialité | Rien ne sort de la machine | Les données transitent par le service |