O modo servidor
O Restorm sabe alojar um servidor, e não apenas chamar um. Define uma rota e a sua resposta, inicia a escuta e depois aponta um cliente para ela — normalmente o código da sua aplicação — para testar a forma como este consome o serviço.
É o que é preciso quando o serviço real ainda não existe, quando é difícil
fazê-lo produzir a resposta que lhe interessa (um erro 503, uma falha SOAP,
um estado gRPC concreto), ou quando quer um conjunto de dados fixo para um
teste reproduzível.
O princípio é simples, e é isso que o torna agradável: o que configura no servidor é a resposta servida. O estado, os cabeçalhos e o corpo que introduz são exatamente aquilo que quem chama recebe.
Protocolos compatíveis
Section titled “Protocolos compatíveis”| Servidor | Página |
|---|---|
| HTTP | Simular uma API HTTP |
| GraphQL | Simular uma API GraphQL |
| gRPC | Simular um serviço gRPC |
| SOAP | Simular um serviço SOAP |
| WebSocket, Socket.IO, MQTT | Simular WebSocket, Socket.IO e MQTT |
| OData | Simular um serviço OData |
Criar um servidor
Section titled “Criar um servidor”Clique com o botão direito numa pasta ▸ Adicionar ▸ e depois a entrada pretendida. O menu oferece oito servidores, sendo cada um deles um tipo de elemento distinto:
Servidor HTTP · Servidor GraphQL · Servidor gRPC · Servidor SOAP · Servidor WebSocket · Servidor Socket.IO · Servidor MQTT · Servidor OData
O elemento criado leva um distintivo SRV na árvore. No caso de um
servidor HTTP, os valores iniciais são GET, localhost:8080/ e estado 200.
Iniciar e parar
Section titled “Iniciar e parar”No painel, o botão de envio é substituído por um comutador Listen ↔ Stop. O painel de resposta mostra o estado em direto: Not listening, ou Listening — N request(s) served.
O host está fixado em localhost: apenas a porta e o caminho são
editáveis. Um servidor de simulação não se destina a ser exposto à rede.
O servidor para através do botão Stop, ao fechar o ficheiro, ou ao sair da aplicação.
Partilha de porta
Section titled “Partilha de porta”O Restorm abre apenas um socket por porta e encaminha conforme a natureza da chamada recebida: os pedidos comuns para as rotas HTTP, os pedidos de mudança de protocolo para WebSocket ou Socket.IO.
Na prática: um servidor HTTP de simulação e um servidor Socket.IO podem
escutar em conjunto na porta :8080. A porta só é libertada quando a sua
última rota é parada.
As variáveis são resolvidas a quente
Section titled “As variáveis são resolvidas a quente”Os cabeçalhos e o corpo servidos são resolvidos no momento de servir, e não no arranque: alterar uma variável de ambiente enquanto o servidor está à escuta muda a resposta seguinte. Consulte Variáveis e ambientes.
Num cenário
Section titled “Num cenário”As ações Escuta … / Fecho … alojam um servidor durante o tempo que o
cenário durar, com uma saída served que emite um evento por cada chamada
recebida. É isso que permite testar um webhook de ponta a ponta num único
grafo. Consulte
Servidores alojados.
Comparação com os servidores de simulação alojados
Section titled “Comparação com os servidores de simulação alojados”| Restorm | Servidores alojados (tipo Postman Mock Servers) | |
|---|---|---|
| Onde é executado | Na sua máquina | No fornecedor |
| Latência | Nenhuma ida e volta pela rede | Uma ida e volta pela Internet |
| Funciona offline | ✔ | ✘ |
| Origem da resposta | O próprio pedido, editável | Um exemplo guardado |
Modelos {{ }} | ✔, resolvidos em cada chamada | Limitados |
| Partilha de porta | ✔ | Não se aplica |
| Privacidade | Nada sai da máquina | Os dados passam pelo serviço |