Migracja z Postmana
1. Eksport z Postmana
Section titled “1. Eksport z Postmana”W Postmanie: Collection ▸ … ▸ Export ▸ Collection v2.1. To samo należy zrobić ze środowiskami.
2. Import do aplikacji Restorm
Section titled “2. Import do aplikacji Restorm”Plik ▸ Importuj (Ctrl+I), a następnie plik JSON. Restorm sam rozpoznaje
format.
Szczegóły: Import kolekcji Postman.
Co przechodzi automatycznie
Section titled “Co przechodzi automatycznie”| Postman | Restorm |
|---|---|
| Foldery | Foldery na tej samej głębokości |
| Żądania HTTP | Żądania HTTP |
| Żądania GraphQL | Żądania GraphQL (a nie żądania HTTP) |
| Treść raw, formdata, urlencoded, file, graphql | Odpowiadający typ treści |
| Zmienne kolekcji | Zmienne środowiska |
| Opisy | Notatki i dokumentacja API |
| Przykładowe odpowiedzi | Dokumentacja API |
| Skrypty wstępne i testowe | Wykonywalny scenariusz wraz z warstwą pm.* |
Co wymaga korekty
Section titled “Co wymaga korekty”Uwierzytelnianie
Section titled “Uwierzytelnianie”Bloki uwierzytelniania Postmana są dokumentowane (z zamaskowanymi wartościami wrażliwymi), ale nie zostają przełożone na działające dane uwierzytelniające.
Wystarczy odtworzyć
żądanie uwierzytelniające — to kwestia
pięciu minut, a w zamian dochodzi automatyczne odnawianie tokenu i ponowna
próba przy 401, czego Postman sam nie robi.
Środowiska
Section titled “Środowiska”Należy je wyeksportować z Postmana i odtworzyć w folderze zmiennych.
To dobra okazja, aby skorzystać z podśrodowisk: tam gdzie Postman narzuca jedno płaskie środowisko na każdy cel, Restorm pozwala na wspólną podstawę i nadpisania dla poszczególnych klientów lub regionów.
Runnery i Newman
Section titled “Runnery i Newman”To najbardziej opłacalna wymiana. Scenariusz robi to samo co runner, tylko lepiej:
- przepływ jest widoczny, a nie ukryty w domyślnej kolejności kolekcji;
- rozgałęzienia, pętle i ponowne próby są blokami, a nie
pm.setNextRequest; - uruchamianie w CI jest wbudowane, z czystymi kodami wyjścia — zob. Uruchamianie headless i CI.
Odpowiedniki pojęć
Section titled “Odpowiedniki pojęć”| Postman | Restorm |
|---|---|
| Workspace | Projekt .restorm, wersjonowany w git |
| Collection | Folder albo folder zmiennych |
| Environment | Środowisko w folderze zmiennych |
| Globals | Środowisko główne, dziedziczone przez elementy potomne |
| Pre-request / Test script | Scenariusz albo akcja kodu |
| Collection Runner | Scenariusz |
| Newman | restorm --run --headless |
| Mock Server | Tryb serwera, lokalnie |
| Monitors | Akcja Czasomierz albo zaplanowane zadanie w CI |
| Postman Console | Konsola |
Zmienne dynamiczne {{$random…}} | Te same, a do nich 116 helperów — zob. referencję |
Zasadnicza różnica
Section titled “Zasadnicza różnica”Żądania stają się plikami w repozytorium. Przechodzą ten sam cykl przeglądu co kod, ich historia jest historią git, a prawa dostępu są tymi z używanej platformy hostingu kodu.
Nie ma hostowanego obszaru roboczego do administrowania ani żadnych danych API
w usłudze zewnętrznej. Zob.
Projekty i pliki .restorm.
A czego Restorm nie ma, a Postman ma
Section titled “A czego Restorm nie ma, a Postman ma”Szczerze mówiąc: Restorm nie ma hostowanego, wspólnego obszaru roboczego, nie ma publicznego portalu API, nie ma komentarzy dodawanych wprost do żądań i nie ma hostowanego monitoringu. Jeśli organizacja opiera się na tych elementach, nie mają one bezpośredniego odpowiednika — współdzielenie odbywa się przez git.