Tryb serwera
Restorm potrafi nie tylko wywołać serwer, lecz także go hostować. Definiuje się trasę oraz jej odpowiedź, uruchamia nasłuchiwanie, a następnie kieruje na nią klienta — zwykle kod własnej aplikacji — aby sprawdzić, w jaki sposób konsumuje on usługę.
Jest to potrzebne wtedy, gdy prawdziwa usługa jeszcze nie istnieje, gdy trudno
zmusić ją do zwrócenia interesującej odpowiedzi (błąd 503, błąd SOAP,
konkretny status gRPC), albo gdy przydaje się zamrożony zestaw danych do
powtarzalnego testu.
Zasada jest prosta i właśnie to czyni ją wygodną: to, co skonfigurowano na serwerze, jest odpowiedzią, która zostaje wysłana. Wpisany status, nagłówki i treść to dokładnie to, co otrzymuje wywołujący.
Obsługiwane protokoły
Section titled “Obsługiwane protokoły”| Serwer | Strona |
|---|---|
| HTTP | Symulowanie API HTTP |
| GraphQL | Symulowanie API GraphQL |
| gRPC | Symulowanie usługi gRPC |
| SOAP | Symulowanie usługi SOAP |
| WebSocket, Socket.IO, MQTT | Symulowanie WebSocket, Socket.IO i MQTT |
| OData | Symulowanie usługi OData |
Tworzenie serwera
Section titled “Tworzenie serwera”Kliknięcie prawym przyciskiem na folderze ▸ Dodaj ▸, a następnie wybór odpowiedniego wpisu. Menu udostępnia osiem serwerów, z których każdy jest osobnym typem elementu:
Serwer HTTP · Serwer GraphQL · Serwer gRPC · Serwer SOAP · Serwer WebSocket · Serwer Socket.IO · Serwer MQTT · Serwer OData
Utworzony element nosi w drzewie plakietkę SRV. Dla serwera HTTP
wartościami początkowymi są GET, localhost:8080/ oraz status 200.
Uruchamianie i zatrzymywanie
Section titled “Uruchamianie i zatrzymywanie”W panelu przycisk wysyłania zostaje zastąpiony przełącznikiem Listen ↔ Stop. Panel odpowiedzi pokazuje stan na bieżąco: Not listening albo Listening — N request(s) served.
Host jest na stałe ustawiony na localhost: edytowalne są wyłącznie port
i ścieżka. Serwer symulacji nie jest przeznaczony do udostępniania w sieci.
Serwer zatrzymuje się przyciskiem Stop, przez zamknięcie pliku albo przez zakończenie pracy aplikacji.
Współdzielenie portu
Section titled “Współdzielenie portu”Restorm otwiera tylko jedno gniazdo na port i kieruje ruch zależnie od charakteru przychodzącego wywołania: zwykłe żądania do tras HTTP, żądania przełączenia protokołu do WebSocket lub Socket.IO.
W praktyce: serwer HTTP symulacji oraz serwer Socket.IO mogą nasłuchiwać razem
na :8080. Port zostaje zwolniony dopiero po zatrzymaniu jego ostatniej
trasy.
Zmienne są rozwiązywane na bieżąco
Section titled “Zmienne są rozwiązywane na bieżąco”Wysyłane nagłówki i treść są rozwiązywane w momencie obsługi wywołania, a nie przy uruchomieniu: zmiana zmiennej środowiskowej w czasie, gdy serwer nasłuchuje, zmienia kolejną odpowiedź. Zob. Zmienne i środowiska.
W scenariuszu
Section titled “W scenariuszu”Akcje Serwer … / Zamknięcie serwera … hostują serwer na czas trwania
scenariusza, a wyjście served emituje jedno zdarzenie na każde
przychodzące wywołanie. To właśnie pozwala przetestować webhook od początku
do końca w jednym grafie. Zob.
Serwery hostowane.
Porównanie z hostowanymi serwerami symulacji
Section titled “Porównanie z hostowanymi serwerami symulacji”| Restorm | Serwery hostowane (w rodzaju Postman Mock Servers) | |
|---|---|---|
| Gdzie to działa | Na własnej maszynie | U dostawcy |
| Opóźnienie | Bez wymiany danych przez sieć | Jedna podróż przez internet |
| Działa bez połączenia | ✔ | ✘ |
| Źródło odpowiedzi | Samo żądanie, edytowalne | Zapisany przykład |
Szablony {{ }} | ✔, rozwiązywane przy każdym wywołaniu | Ograniczone |
| Współdzielenie portu | ✔ | Nie dotyczy |
| Prywatność | Nic nie opuszcza maszyny | Dane przechodzą przez usługę |