Servir le design en mock
Une fois vos modèles et vos routes définis, Restorm sait servir votre design comme un vrai serveur mock. Vous pointez votre application (ou un client) dessus et vous testez la façon dont elle consomme l’API — avant même que le back-end n’existe.
Démarrer le serveur
Section titled “Démarrer le serveur”Dans la section Serveur, activez Servir ce design, choisissez un
port et démarrez l’écoute. Vous pouvez ajouter une latence simulée pour
imiter un réseau réel, et activer le mode avec état : les POST / PUT /
DELETE modifient alors un magasin en mémoire (réinitialisé au redémarrage).
Le serveur refuse de démarrer tant que le design présente des problèmes de validation — corrigez-les d’abord.
Les réponses servies proviennent d’abord de vos exemples nommés, puis d’un
jeu de données généré automatiquement. Le serveur expose aussi un
/swagger.json.
Un design, tous les protocoles
Section titled “Un design, tous les protocoles”C’est le cœur du mode mock : HTTP est toujours servi, et chaque autre protocole s’active avec un simple interrupteur Servir aussi cette projection. Restorm projette automatiquement vos routes — d’après leur méthode, leur chemin et leurs modèles — dans chaque protocole :
| Protocole | Projection |
|---|---|
| HTTP | Vos routes REST, telles que définies. |
| GraphQL | Requêtes et mutations correspondantes. |
| SOAP | Opérations et enveloppes. |
| OData | Jeux d’entités interrogeables. |
| gRPC | Méthodes et messages. |
Un panneau Projections montre, pour une route donnée, sa signature dans chaque protocole servi — « la même opération, telle que chaque protocole l’expose ».
Suivre et forcer les réponses
Section titled “Suivre et forcer les réponses”Pendant l’exécution, un panneau indique l’adresse d’écoute et le nombre d’appels servis. Vous pouvez forcer une réponse (un statut, un corps précis) sur une route pour reproduire un cas particulier, puis arrêter le serveur quand vous avez terminé.