El modo servidor
Restorm sabe alojar un servidor, y no solo llamar a uno. Usted define una ruta y su respuesta, inicia la escucha y después apunta un cliente a ella —normalmente el código de su aplicación— para probar la forma en que consume el servicio.
Es lo que hace falta cuando el servicio real aún no existe, cuando es difícil hacer que
produzca la respuesta que le interesa (un error 503, un fallo SOAP, un estado gRPC concreto),
o cuando quiere un juego de datos fijo para una prueba reproducible.
El principio es simple, y es lo que lo hace agradable: lo que usted configura en el servidor es la respuesta servida. El estado, las cabeceras y el cuerpo que introduce son exactamente lo que recibe quien llama.
Protocolos compatibles
Section titled “Protocolos compatibles”| Servidor | Página |
|---|---|
| HTTP | Simular una API HTTP |
| GraphQL | Simular una API GraphQL |
| gRPC | Simular un servicio gRPC |
| SOAP | Simular un servicio SOAP |
| WebSocket, Socket.IO, MQTT | Simular WebSocket, Socket.IO y MQTT |
| OData | Simular un servicio OData |
Crear un servidor
Section titled “Crear un servidor”Clic derecho sobre una carpeta ▸ Añadir ▸ y después la entrada deseada. El menú ofrece ocho servidores, cada uno de ellos un tipo de elemento distinto:
Servidor HTTP · Servidor GraphQL · Servidor gRPC · Servidor SOAP · Servidor WebSocket · Servidor Socket.IO · Servidor MQTT · Servidor OData
El elemento creado lleva un distintivo SRV en el árbol. En el caso de un servidor HTTP,
los valores de partida son GET, localhost:8080/ y estado 200.
Iniciar y detener
Section titled “Iniciar y detener”En el panel, el botón de envío se sustituye por un conmutador Listen ↔ Stop. El panel de respuesta muestra el estado en directo: Not listening, o Listening — N request(s) served.
El host está fijado en localhost: solo el puerto y la ruta son editables. Un servidor de
simulación no está pensado para exponerse a la red.
El servidor se detiene con el botón Stop, al cerrar el archivo, o al salir de la aplicación.
Compartición de puerto
Section titled “Compartición de puerto”Restorm solo abre un socket por puerto y encamina según la naturaleza de la llamada entrante: las peticiones ordinarias hacia las rutas HTTP y las solicitudes de cambio de protocolo hacia WebSocket o Socket.IO.
En la práctica: un servidor HTTP de simulación y un servidor Socket.IO pueden escuchar juntos en
:8080. El puerto solo se libera al detener su última ruta.
Las variables se resuelven en caliente
Section titled “Las variables se resuelven en caliente”Las cabeceras y el cuerpo servidos se resuelven en el momento de servir, no al arrancar: modificar una variable de entorno mientras el servidor escucha cambia la respuesta siguiente. Consulte Variables y entornos.
En un escenario
Section titled “En un escenario”Las acciones Escucha … / Cierre … alojan un servidor durante el tiempo que dura el
escenario, con una salida served que emite un evento por cada llamada entrante. Es lo que
permite probar un webhook de extremo a extremo en un solo grafo. Consulte
Servidores alojados.
Comparación con los servidores de simulación alojados
Section titled “Comparación con los servidores de simulación alojados”| Restorm | Servidores alojados (tipo Postman Mock Servers) | |
|---|---|---|
| Dónde se ejecuta | En su máquina | En el proveedor |
| Latencia | Ningún viaje de ida y vuelta por la red | Un viaje de ida y vuelta por Internet |
| Funciona sin conexión | ✔ | ✘ |
| Origen de la respuesta | La propia petición, editable | Un ejemplo guardado |
Plantillas {{ }} | ✔, resueltas en cada llamada | Limitadas |
| Compartición de puerto | ✔ | No aplicable |
| Confidencialidad | Nada sale de la máquina | Los datos pasan por el servicio |