Redakcja testerzy.pl
AsyncAPI 3.0 w Spec Hub
Obsługa architektury sterowanej zdarzeniami (Event-Driven Architecture), wykorzystującej narzędzia takie jak Apache Kafka, MQTT czy WebSockets, zyskała nowe udogodnienie. Postman wprowadził pełne wsparcie dla specyfikacji AsyncAPI 3.0. Projektanci otrzymali do dyspozycji edytor z funkcją podpowiadania składni, automatycznym sprawdzaniem błędów oraz podglądem dokumentacji w czasie rzeczywistym, na analogicznych zasadach jak miało to miejsce przy OpenAPI.
Wersja AsyncAPI 3.0 wprowadza przemodelowaną strukturę, w której odseparowano kanały od operacji. Taki układ ułatwia ponowne wykorzystanie fragmentów kodu i eliminuje dwuznaczności, co pozwoliło twórcom oprogramowania zewnętrznego na stabilną implementację tego standardu.
Nowe pliki można tworzyć z poziomu paska bocznego, menu dzięki opcji „+ New” lub za pomocą trybu Postman Agent. Narzędzie importu obsługuje format v3 poprzez wczytanie pliku, wskazanie odnośnika, wczytanie całego folderu lub wklejenie kodu. Edytor wyposażono w szablony dedykowane dla tej wersji, autouzupełnianie referencji $ref oraz nowy komponent struktury – Operations.
Osoby pracujące na lokalnych repozytoriach Git mogą korzystać z automatycznego wykrywania plików v3 na dysku w lokalnych przestrzeniach roboczych, bez konieczności modyfikowania ustawień. Zmiany uwzględniono także w Postman API (wersja v1.41.0), co pozwala na programistyczne zarządzanie plikami (tworzenie, odczyt i aktualizację) za pomocą punktu końcowego /specs.
Ujednolicony panel diagnostyki
Modyfikacja interfejsu polega na połączeniu rozproszonych dotychczas paneli walidacji. Wcześniej każda otwarta specyfikacja miała osobny widok weryfikacji błędów, co wymuszało przełączanie się między kartami przy pracy nad wieloma plikami równocześnie.
Obecnie komunikaty o błędach, ostrzeżenia oraz uwagi informacyjne trafiają do jednego, wspólnego okna. Wykryte nieprawidłowości są segregowane według konkretnego pliku i typu reguły (z podziałem na składnię oraz standardy narzucone przez reguły governance). Nawigacja odbywa się za pomocą struktury drzewka.
Dolny pasek stanu edytora zyskał licznik prezentujący liczbę uwag dla aktualnie otwartej karty. Jego kliknięcie otwiera panel diagnostyczny automatycznie przefiltrowany do tego konkretnego pliku. Użytkownik może też filtrować widok na podstawie stopnia krytyczności komunikatów, co pozwala tymczasowo ukryć drobne ostrzeżenia i skupić się wyłącznie na naprawie błędów blokujących.
Przenoszenie projektów między przestrzeniami roboczymi
Wprowadzona funkcja rozwiązuje problem powielania plików. Do tej pory brak opcji bezpośredniego przenoszenia specyfikacji wymuszał tworzenie ich kopii w różnych przestrzeniach roboczych. Prowadziło to do powstawania rozbieżności między wersjami tego samego projektu.
Nowa opcja „Przenieś” w menu specyfikacji pozwala wskazać docelowy obszar roboczy. Przeniesieniu ulega cała struktura, metadane oraz powiązania między plikami w projektach wieloplikowych. Funkcja ta obsługuje wszystkie formaty dostępne w Postmanie: OpenAPI (2.0, 3.0, 3.1), AsyncAPI 2.0, GraphQL oraz Protocol Buffers (protobuf).
Podgląd testów wydajnościowych na żywo i automatyczna weryfikacja
Dotychczasowe uruchamianie testów obciążeniowych przez interfejs wiersza poleceń (Postman CLI) wymagało wygenerowania pełnego raportu po zakończeniu całego cyklu. W przypadku awarii API na początku testu, proces weryfikacji i tak trwał przez założony czas, co niepotrzebnie zajmowało zasoby w procesie CI/CD.
Obecnie uruchomienie testu z poziomu CLI (zarówno lokalnie, jak i w środowisku automatyzacji) umożliwia śledzenie wskaźników w aplikacji Postman w czasie rzeczywistym. Wykresy prezentujące czasy odpowiedzi, przepustowość oraz procent błędów odświeżają się na bieżąco. Pozwala to na natychmiastowe przerwanie testu w celu eliminacji usterki, bez czekania na zakończenie zaplanowanego przebiegu.
Automatyczne progi walidacji
Po aktualizacji Postman CLI zyskał możliwość definiowania kryteriów akceptacji (m.in. maksymalnego czasu odpowiedzi czy dopuszczalnego procentu nieudanych żądań). Przekroczenie wyznaczonych wartości granicznych sprawia, że narzędzie CLI zwraca błąd (niezerowy kod wyjścia), co pozwala automatycznie zatrzymać dalsze kroki wdrożeniowe w środowisku CI/CD. Rozwiązanie to ułatwia wcześniejsze wykrywanie problemów z wydajnością przed wdrożeniem zmian. Funkcja została udostępniona dla użytkowników planu Solo oraz wyższych.
Konta systemowe dla planów Enterprise
Service accounts (konta systemowe) wprowadzają tożsamość maszynową przeznaczoną do obsługi automatyzacji i integracji systemowych, zastępując imienne klucze API pracowników. Mechanizm autoryzacji wykorzystuje krótkotrwałe tokeny JWT. Stały klucz konta systemowego jest wymieniany na token ważny przez 15 minut, który przenosi informacje o uprawnieniach. Eliminuje to potrzebę przechowywania długoterminowych danych uwierzytelniających w zmiennych konfiguracyjnych procesów automatyzacji.
Rozwiązanie to usuwa dwie trudności związane z używaniem kont osobistych:
- zasada minimalnych uprawnień – konto systemowe otrzymuje dostęp wyłącznie do zasobów niezbędnych do wykonania danego zadania, podczas gdy klucz pracownika zazwyczaj dawał szerszy wgląd w projekty.
- ciągłość działania struktur automatyzacji – odejście członka zespołu z firmy i dezaktywacja jego konta osobistego nie powoduje przerwania działania skryptów korzystających z konta systemowego.
Ograniczenie ważności tokenów do kwadransa i precyzyjne dawkowanie uprawnień zmniejszają ryzyko nieautoryzowanego dostępu w przypadku przechwycenia danych uwierzytelniających. Opcja ta jest dostępna dla subskrypcji Enterprise.
Z pełnym opisem nowości w Postmanie możecie zapoznać się na oficjalnej stronie narzędzia.
