Przejdź do głównej zawartości

Import kolekcji Postman

Restorm importuje kolekcje Postman v2.0 i v2.1 (format tworzony przez „Export ▸ Collection v2.1” w Postmanie).

Plik ▸ Importuj (Ctrl+I), a następnie wyeksportowany plik .json.

Drzewo utworzone przez import kolekcji Postman: folder zmiennych w korzeniu, jeden podfolder na każdy folder Postmana oraz jedno żądanie na wpis, wraz z jego czasownikiem

Element PostmanaCo z tym robi Restorm
Foldery (zagnieżdżone item)Foldery na tej samej głębokości
ŻądaniaŻądania HTTP — albo GraphQL, gdy treść jest typu graphql
Treść raw, formdata, urlencoded, file, graphqlOdpowiadający typ treści
Zmienne kolekcjiZmienne środowiska
OpisyNotatki żądania oraz dokumentacja API
Przykładowe odpowiedziDokumentacja API

To właśnie wyróżnia ten import. Skrypty wstępne i testowe nie przepadają: zostają zachowane w dokumentacji oraz przekształcone w wykonywalny scenariusz, w którym bloki kodu uruchamiają skrypt w niezmienionej postaci.

Służy do tego warstwa zgodności pm.*, którą Restorm udostępnia w swoich akcjach kodu JavaScript: pm.environment, pm.variables, pm.response, pm.test, pm.expect, pm.sendRequest, pm.setNextRequest, pm.cookies… Istniejące asercje działają więc dalej, bez przepisywania.

Bloki uwierzytelniania Postmana (oauth2, apikey, bearer, basic, digest, hawk, aws, ntlm, edgegrid) są odczytywane i streszczane w dokumentacji API, przy czym wartości wrażliwe zostają zamaskowane.

Nie są one przekładane na działające dane uwierzytelniające: wystarczy odtworzyć trasę uwierzytelniania — to kwestia pięciu minut, a w zamian dochodzi automatyczne odnawianie tokenu.

Postman należy do formatów, które można ponownie synchronizować (jeśli kolekcja została zaimportowana z adresu URL): przycisk Odśwież w folderze pobiera źródło, a Restorm stosuje różnicę. Zob. Aktualizacja ze źródła.

Przewodnik Migracja z Postmana omawia pełną migrację, wraz ze środowiskami i runnerami.