Mocking an HTTP API

Right-click a folder ▸ Add ▸ HTTP server.

Configuring

A server is configured with the same fields as a request — and that is the whole point: the method and the path define the route listened on, while the status, the headers and the body define the response served.

Field	Role
Method	The route’s method
Address	localhost:<port><path> — the host is fixed
Mock status	The code returned, 200 by default
Headers	The response’s headers
Body	The response’s body

Routing

A route is a method + path pair. Matching is on the exact path, and the query string is ignored. Any call arriving on the port without matching a route gets a 404.

Two routes only collide if they share the same method, the same path and the same port. You can therefore create one server request per route and start them all.

GET  localhost:8080/clients      → 200, liste de clients
GET  localhost:8080/clients/42   → 200, un client
POST localhost:8080/clients      → 201, en-tête Location
GET  localhost:8080/clients/999  → 404 (aucune route : réponse par défaut)

Templates

The headers and the body are resolved on every inbound call. A body containing {{maintenant}} or {{compteur}} therefore changes from one call to the next if the variable changes.

A tip: this lets you drive the server’s behaviour while it is running — change an environment variable’s value and the next call gets a different response, with no restart.

Port sharing

A mock HTTP server and a WebSocket or Socket.IO server can listen on the same port: Restorm dispatches ordinary requests to the HTTP routes and upgrade requests to the real-time server.

In a scenario

The HTTP server action hosts the route for the duration of the scenario and emits a served event — carrying { request, response } — per call received. That is how you test a webhook:

Serveur HTTP ──connected──► Requête HTTP « déclencher le webhook »
     └────────served──────► Assert sur request.body
                              puis ──► Fermeture serveur HTTP

See Hosted servers.