Serwowanie projektu jako mock

Gdy Pana/Pani modele i trasy są już zdefiniowane, Restorm potrafi serwować Pana/Pani projekt jak prawdziwy serwer mock. Kieruje Pan/Pani na niego swoją aplikację (lub klienta) i testuje sposób, w jaki konsumuje ona API — jeszcze zanim powstanie back-end.

Sekcja Serwer: projekt nasłuchujący na porcie, z rzutowanymi protokołami i licznikiem wywołań

Uruchamianie serwera

W sekcji Serwer proszę włączyć Serwuj ten projekt, wybrać port i uruchomić nasłuchiwanie. Może Pan/Pani dodać symulowane opóźnienie, aby naśladować prawdziwą sieć, oraz włączyć tryb ze stanem: POST / PUT / DELETE modyfikują wtedy magazyn w pamięci (resetowany przy ponownym uruchomieniu).

Serwer odmawia uruchomienia, dopóki projekt ma problemy z walidacją — najpierw proszę je poprawić.

Serwowane odpowiedzi pochodzą najpierw z Pana/Pani nazwanych przykładów, a następnie z automatycznie wygenerowanego zestawu danych. Serwer udostępnia także /swagger.json.

Jeden projekt, wszystkie protokoły

To sedno trybu mock: HTTP jest zawsze serwowany, a każdy inny protokół włącza się prostym przełącznikiem Serwuj także to rzutowanie. Restorm automatycznie rzutuje Pana/Pani trasy — na podstawie ich metody, ścieżki i modeli — na każdy protokół:

Protokół	Rzutowanie
HTTP	Pana/Pani trasy REST, tak jak zdefiniowane.
GraphQL	Odpowiadające zapytania i mutacje.
SOAP	Operacje i koperty.
OData	Przeszukiwalne zestawy encji.
gRPC	Metody i komunikaty.

Panel Rzutowania pokazuje dla danej trasy jej sygnaturę w każdym serwowanym protokole — „ta sama operacja, tak jak wystawia ją każdy protokół”.

Śledzenie i wymuszanie odpowiedzi

W trakcie działania panel wskazuje adres nasłuchiwania i liczbę obsłużonych wywołań. Może Pan/Pani wymusić odpowiedź (status, konkretną treść) na trasie, aby odtworzyć szczególny przypadek, a następnie zatrzymać serwer, gdy skończy.