← Wszystkie wpisy
Aktualizacja produktu 5 min czytania

Playground: twórz i testuj requesty w swoim Dashboardzie

Wdrożyliśmy Playground wewnątrz Dashboardu. Wybierz endpoint, wypełnij pola, kliknij Send i skopiuj curl. Trzy endpointy, jeden cookie jar, każdy header.

playgrounddashboarddeveloper-experienceapi

Playground jest już dostępny w Twoim Dashboardzie. Trzy endpointy, jeden cookie jar, każdy header sparsowany. Wybierz Single, Proxy lub Browser, uzupełnij request i kliknij Send. Response pojawia się na tym samym ekranie wraz ze statusem, headerami, body i sparsowanymi cookies. Gdy wszystko działa jak należy, skopiuj gotowy curl do swojego kodu.

To nie jest osobna strona ani sandbox ukryty pod innym URL. Narzędzie działa na żywym API z użyciem Twojego prawdziwego klucza. To, co widzisz w Playground, jest dokładnie tym, co zwróci Twój kod produkcyjny.

Jak to działa

Logujesz się do Dashboardu, wybierasz jeden z trzech endpointów, a formularz automatycznie się przebudowuje, aby pokazać tylko te pola, które dany endpoint faktycznie obsługuje.

  • Single otrzymuje url, method, headers, unblocker, proxy, tryJsonData, followRedirects oraz grupę timeout.
  • Proxy otrzymuje ten sam zestaw opakowany w blok request, plus filtry wyboru proxy (kraj, miasto, ASN, anonimowość, świeżość).
  • Browser otrzymuje url, cookies, headers oraz warunki oczekiwania.

Gdy klikasz Send, Dashboard uwierzytelnia połączenie na Twoim koncie i wysyła POST do /api/{endpoint} na api.foura.ai. Twój prawdziwy API key nigdy nie przechodzi przez stronę. Playground to jedyne miejsce w Dashboardzie, w którym możesz uruchomić płatny request bez ujawniania klucza w przeglądarce.

Oto curl, który Playground generuje dla podstawowego requestu Single:

curl -X POST 'https://api.foura.ai/api/single' \
  -H 'Content-Type: application/json' \
  -H 'x-api-key: YOUR_API_KEY' \
  --data-raw '{
    "url": "https://example.com/products",
    "method": "GET",
    "unblocker": true,
    "tryJsonData": true
  }'

Wklej go do terminala lub skryptu budowania, a zachowa się dokładnie tak samo jak przycisk Send. Nie opakowujemy payloadu w żadne niestandardowe struktury ani nie zmieniamy nazw pól. Playground wysyła dokładnie to, co przyjmuje API, kropka.

Co otrzymujesz w odpowiedzi

Panel odpowiedzi pokazuje status upstream, całkowity czas oraz (dla wywołań Proxy) proxy id, które obsłużyło request. Body, Headers i Cookies mają swoje własne zakładki.

Body. Automatycznie wykryty JSON jest renderowany w rozwijanym widoku. Payloady HTML przełączają się na panel podglądu, dzięki czemu możesz szybko ocenić, co zwróciła docelowa strona. Tekst jest wyświetlany w prostym widoku monospace. W zakładkach Body i Raw dostępna jest wyszukiwarka z przechodzeniem do poprzedniego/następnego wyniku.

Headers. Widok sparsowany z jednym wierszem na name: value lub Raw dla pełnego łańcucha odpowiedzi multi-hop. Każde przekierowanie pozostawia po sobie własny zestaw headerów, więc śledzenie 302 do ostatecznego celu to kwestia jednego kliknięcia.

Cookies. Cookie jar parsuje każdą linijkę Set-Cookie z response, sprawdza, czy dany cookie jest host-only czy domain-wide (RFC 6265 §5.3), i oferuje dwa widoki: rozwijane karty dla poszczególnych hostów lub surową listę. Włącz cookie jar, a kolejny request automatycznie pobierze pasujące cookies. Dla Single i Proxy oznacza to header Cookie w wychodzącym requeście. Dla Browser oznacza to tablicę cookies dołączoną do obiektu requestu.

Presety zapisują całą konfigurację requestu pod wybraną nazwą i opisem, dzięki czemu możesz szybko wrócić do "test login on staging" bez ponownego jej konfigurowania. Historia przechowuje Twoje ostatnie dwadzieścia uruchomień wraz ze statusem, content type, całkowitym czasem i użytym proxy.

Wpływ

To, co Playground naprawdę zmienia, to pętla iteracji.

Wcześniej pisałeś prosty skrypt (Node, Python lub shell), podłączałeś klucz, uderzałeś do API, wypisywałeś body, poprawiałeś jeden header i uruchamiałeś go ponownie. Schodziło jakieś dziesięć minut od „ciekawe, co ta strona zwraca” do uzyskania odpowiedzi.

W Playground ta pętla trwa bliżej piętnastu sekund. Klikasz endpoint, wklejasz URL, klikasz Send, patrzysz na cookies, zmieniasz unblocker z off na on, klikasz ponownie Send. Zanim zdążysz otworzyć edytor, już wiesz, która wersja requestu działa na Twoim celu.

Nie wdrożyliśmy Playground, aby zastąpić Twój prawdziwy kod. Zrobiliśmy to po to, aby droga od „czy to w ogóle da się zrobić na tej stronie” do „tak, oto działający curl” przestała wymagać tworzenia pobocznego projektu.

Dla zaawansowanych użytkowników

Kilka rzeczy, które nie są oczywiste na pierwszy rzut oka:

Presety zawierają pełny payload. Obejmuje to grupę timeout, reguły walidacji, limit przekierowań i wszelkie niestandardowe headery. Zapisując preset, robisz snapshot przetestowanego requestu, a nie tylko samego URL. Przydatne, gdy utrzymujesz zestaw stabilnych smoke tests na różnych endpointach.

Cookie jar działa w obrębie sesji. Żyje w Twojej przeglądarce. Nie przechowujemy przechwyconych cookies po stronie serwera. Wykonaj hard-reload karty, jeśli potrzebujesz czystego stanu.

Zakładka Raw i formularz pozostają zsynchronizowane. Pola formularza renderują ten sam JSON, który widać w zakładce Raw. Wklej payload do Raw, a formularz automatycznie się uzupełni. Dzięki temu współpracownik może wrzucić działający request na czacie, Ty wklejasz go do Raw, a formularz sam się wypełnia.

Cookies w Browser mają strukturę obiektową, a nie nagłówkową. Jeśli wysyłasz cookies do endpointu Browser ręcznie, każdy wpis przyjmuje postać {name, value, domain?, path?, httpOnly?, secure?, sameSite?}. Playground buduje je poprawnie, gdy cookie jar jest włączony. Jeśli tworzysz je samodzielnie, zgodność ze schematem ma kluczowe znaczenie.

Outcomes pojawiają się w Twoim activity feed. Kiedy Playground wysyła request, liczy się on tak samo jak każde inne wywołanie z użyciem Twojego klucza. Zobaczysz go w activity logu z odpowiednią etykietą outcome (success, client_error, application_error, rate_limit, service_error). Przydatne do repro niestabilnego połączenia produkcyjnego: uruchom je ponownie w Playground, znajdź w activity logu i udostępnij link zespołowi.

Co dalej

Playground to pierwszy krok w kierunku zmian, dzięki którym Dashboard będzie robił więcej niż tylko pokazywał to, co już zostało zrobione. Wzorce, które widzimy w request logu, kształtują to, co wdrożymy w następnej kolejności.

Jeśli korzystasz z niego dzisiaj i coś wydaje się nie tak – pole, które nie pasuje do dokumentacji, cookie, który nie przetrwał przekierowania, czy response, który błędnie się renderuje – to właśnie na taki feedback czekamy w pierwszej kolejności. Dashboard widzi requesty. My widzimy trendy.