← Wszystkie wpisy
Aktualizacja produktu 5 min czytania

Playground: Buduj i testuj requesty w swoim Dashboardzie

Wdrożyliśmy Playground w Dashboardzie. Wybierz endpoint, wypełnij pola, kliknij Send, skopiuj curl. Trzy endpointy, jeden cookie jar, każdy nagłówek.

playgrounddashboarddeveloper-experienceapi

Playground jest już dostępny w Twoim Dashboardzie. Trzy endpointy, jeden cookie jar, każdy sparsowany nagłówek. Wybierz Single, Proxy lub Browser, wypełnij request, kliknij Send. Response pojawia się na tym samym ekranie ze statusem, nagłówkami, ciałem i sparsowanymi cookies. Gdy będziesz zadowolony, skopiuj działający curl do swojego kodu.

To nie jest osobna strona ani sandbox ukryty pod innym URL. Działa on na żywym API z Twoim prawdziwym kluczem. To, co widzisz w Playground, jest tym, co otrzyma Twój kod produkcyjny.

Jak to działa

Logujesz się do Dashboardu, wybierasz jeden z trzech endpointów, a formularz przebudowuje się, aby pokazać tylko pola faktycznie akceptowane przez ten endpoint.

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

Kiedy klikniesz Send, Dashboard uwierzytelnia wywołanie w Twoim koncie i wysyła POST do /api/{endpoint} w api.foura.ai. Twój prawdziwy klucz API nigdy nie przechodzi przez stronę. Playground to jedyne miejsce w Dashboardzie, gdzie możesz wysłać płatny request bez ujawniania klucza w przeglądarce.

Oto reproduktor curl, który Playground wypluwa 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 to do terminala lub skryptu budującego, a zadziała to dokładnie jak przycisk Send. Nie opakowujemy payloadu w niestandardową kopertę ani nie zmieniamy nazw żadnych pól. Playground wysyła to, co przyjmuje API, kropka.

Co otrzymujesz z powrotem

Panel response pokazuje status upstream, całkowity czas oraz (dla wywołań Proxy) identyfikator proxy, który obsłużył request. Body, Headers i Cookies otrzymują własne zakładki.

Body. Automatycznie wykryty JSON renderuje się w zwijanej przeglądarce. Payloady HTML przełączają się do panelu podglądu, abyś mógł zobaczyć, co zwróciła strona docelowa. Tekst trafia do zwykłego widoku o stałej szerokości znaku. Na Body i Raw znajduje się pole wyszukiwania ze skokami do poprzedniego/następnego wyniku.

Headers. Sparsowany widok z jednym wierszem na name: value, lub Raw dla pełnego wieloetapowego łańcucha response. Każde przekierowanie zostawia za sobą własny zestaw nagłówków, więc śledzenie 302 do celu docelowego to jedno kliknięcie.

Cookies. Cookie jar parsuje każdą linię Set-Cookie z response, śledzi, czy każdy cookie jest host-only czy domain-wide (RFC 6265 §5.3), i oferuje dwa widoki: zwijane karty dla każdego hosta lub surową listę. Włącz jar, a następny request automatycznie pobierze pasujące cookies. Dla Single i Proxy oznacza to nagłówek Cookie w wychodzącym requeście. Dla Browser oznacza to tablicę cookie dołączoną do obiektu request.

Presety zapisują całą konfigurację requestu pod nazwą i opisem, więc możesz wrócić do "test login on staging" bez jej ponownego budowania. Historia przechowuje Twoje ostatnie dwadzieścia uruchomień ze statusem, typem treści, całkowitym czasem i użytym proxy.

Wpływ

Tym, co Playground faktycznie zmienia, jest pętla iteracyjna.

Wcześniej pisałeś mały skrypt (Node, Python lub powłoka), podłączałeś swój klucz, uderzałeś w API, drukowałeś body, poprawiałeś jeden nagłówek, uruchamiałeś to ponownie. Może dziesięć minut od "ciekawe, co ta strona zwraca" do uzyskania odpowiedzi.

W Playground ta pętla jest bliższa piętnastu sekundom. Klikasz endpoint, wklejasz URL, klikasz Send, sprawdzasz cookies, zmieniasz unblocker z wyłączonego na włączony, klikasz ponownie Send. Zanim otworzyłbyś edytor, już wiesz, która wersja requestu działa na Twoim celu.

Nie wdrożyliśmy Playground, aby zastąpić Twój prawdziwy kod. Wdrożyliśmy go, aby droga od "czy to jest w ogóle wykonalne na tej stronie" do "tak, oto działający curl" przestała wymagać pobocznego projektu.

Dla Power Userów

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

Presety niosą pełny payload. Obejmuje to grupę timeout, zasady walidacji, limit przekierowań i wszelkie niestandardowe nagłówki. Zapisując preset, robisz snapshot przetestowanego requestu, a nie tylko URL. Przydatne, gdy przechowujesz zestaw stabilnych testów dymnych dla wielu endpointów.

Cookie jar jest przypisany do sesji. Żyje w Twojej przeglądarce. Nie zachowujemy przechwyconych cookies po stronie serwera. Zrób hard-reload karty, jeśli potrzebujesz czystego stanu.

Zakładka Raw i formularz pozostają zsynchronizowane. Pola formularza renderują ten sam JSON, który pokazuje zakładka Raw. Wklej payload do Raw, a formularz się zaktualizuje. Więc współpracownik może wrzucić działający request na czacie, Ty wklejasz go do Raw, a formularz wypełnia się sam.

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

Wyniki pojawiają się w Twoim strumieniu aktywności. Kiedy Playground odpala request, liczy się on tak samo jak każde inne wywołanie przy użyciu Twojego klucza. Zobaczysz go w swoim logu aktywności z odpowiednią etykietą wyniku (success, client_error, application_error, rate_limit, service_error). Przydatne do reprodukcji niestabilnego wywołania produkcyjnego: uruchom je ponownie w Playground, znajdź w logu aktywności, udostępnij link zespołowi.

Co dalej

Playground to pierwszy krok w większym dążeniu, aby Dashboard robił więcej niż tylko pokazywał to, co już zrobiłeś. Wzorce, które widzimy w logu requestów, kształtują to, co wdrożymy w następnej kolejności.

Jeśli używasz tego dzisiaj i coś wydaje się nie tak, pole, które nie pasuje do dokumentacji, cookie, które nie przetrwało przekierowania, response, który źle się renderuje, to jest feedback, który czytamy w pierwszej kolejności. Dashboard widzi requesty. My widzimy trendy.