← Всички публикации
Продуктово обновление 5 мин. четене

The Playground: Създавайте и тествайте requests във вашия Dashboard

Добавихме Playground в Dashboard. Изберете endpoint, попълнете полетата, натиснете Send, копирайте curl. Три endpoints, един cookie jar, всеки header.

playgrounddashboarddeveloper-experienceapi

Playground е активен във вашия Dashboard. Три endpoints, един cookie jar, всеки header е парснат. Изберете Single, Proxy или Browser, попълнете request, натиснете Send. Response се зарежда на същия екран със status, headers, body и парснати cookies. Когато сте готови, копирайте работещия curl в кода си.

Това не е отделна страница или sandbox, намиращ се зад различен URL. Работи директно срещу реалното API с вашия истински ключ. Това, което виждате в Playground, е точно това, което вашият production код ще получи обратно.

How It Works

Влизате в Dashboard, избирате един от трите endpoints и формата се преструктурира, за да покаже само полетата, които този endpoint действително приема.

  • Single получава url, method, headers, unblocker, proxy, tryJsonData, followRedirects и групата за timeout.
  • Proxy получава същия набор, обвит в request блок, плюс филтрите за избор на proxy (държава, град, ASN, анонимност, свежест).
  • Browser получава url, cookies, headers и wait conditions.

Когато натиснете Send, Dashboard удостоверява повикването към вашия акаунт и изпраща POST към /api/{endpoint} на api.foura.ai. Вашият реален API key никога не преминава през страницата. Playground е единственото място в Dashboard, където можете да задействате платен request, без да излагате ключа в браузъра.

Ето и curl командата, която Playground генерира за базов Single request:

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
  }'

Поставете това в терминал или build скрипт и то ще се държи точно като бутона Send. Ние не обвиваме payload в персонализиран формат и не преименуваме никое от полетата. Playground изпраща това, което API приема, и точка.

What You See Back

Панелът за response показва upstream status, общото време и (за Proxy повиквания) proxy id, което е обработило request. Body, Headers и Cookies получават свой собствен раздел.

Body. Автоматично разпознатият JSON се рендерира в сгъваем изглед. HTML payloads превключват към preview панел, за да можете да хвърлите едно око на това, което целевият сайт е върнал. Текстът се показва в изчистен monospace изглед. Има поле за търсене в Body и Raw с навигация напред/назад.

Headers. Парснат изглед с по един ред за name: value или Raw за пълната multi-hop response верига. Всеки redirect оставя свой собствен набор от headers, така че проследяването на 302 до крайната му дестинация става с един клик.

Cookies. Cookie jar-ът парсва всеки Set-Cookie ред от response, проследява дали всяко cookie е host-only или domain-wide (RFC 6265 §5.3) и предлага два изгледа: сгъваеми карти за всеки host или raw списък. Включете jar-а и следващият request автоматично ще изтегли съвпадащите cookies. За Single и Proxy това означава Cookie header в изходящия request. За Browser това означава cookie масив, прикрепен към request обекта.

Presets запазват цялата request конфигурация под име и описание, така че можете бързо да се върнете към „test login on staging“, без да я изграждате наново. History пази последните ви двадесет изпълнения със status, content type, общо време и използваното proxy.

Impact

Това, което Playground действително променя, е итерационният цикъл.

Преди пишехте малък скрипт (Node, Python или shell), свързвахте ключа си, викахте API, принтирахте body, променяхте един header, стартирахте го отново. Може би десет минути от „чудя се какво ли връща този сайт“ до получаването на отговор.

В Playground този цикъл е по-близо до петнадесет секунди. Кликнете върху endpoint, поставете URL, натиснете Send, погледнете cookies, променете unblocker от off на on, натиснете Send отново. Докато отворите редактора си, вече знаете коя версия на request работи за вашата цел.

Не пуснахме Playground, за да заменим реалния ви код. Пуснахме го, за да може пътят от „възможно ли е изобщо това на този сайт“ до „да, ето работещия curl“ да спре да изисква създаването на страничен проект.

For Power Users

Няколко неща, които не са очевидни на пръв поглед:

Presets пренасят целия payload. Това включва групата за timeout, правилата за валидация, лимита за redirects и всички персонализирани headers. Когато запазвате preset, вие правите snapshot на тестван request, а не просто на URL. Полезно е, когато поддържате набор от стабилни smoke тестове в различните endpoints.

Cookie jar-ът е per-session. Той живее във вашия браузър. Ние не запазваме заснетите cookies server-side. Направете hard-reload на таба, ако имате нужда от чисто състояние.

Табът Raw и формата остават синхронизирани. Полетата на формата рендерират същия JSON, който показва табът Raw. Поставете payload в Raw и формата се рехидратира. Така колега може да пусне работещ request в чата, вие го поставяте в Raw и формата се попълва сама.

Browser cookies са структурирани като обекти, а не като headers. Ако изпращате cookies към Browser endpoint ръчно, всеки запис приема {name, value, domain?, path?, httpOnly?, secure?, sameSite?}. Playground ги изгражда правилно, когато jar-ът е включен. Ако ги създавате сами, съвпадението на схемата е от значение.

Outcomes се показват във вашия activity feed. Когато Playground задейства request, той се отчита по същия начин, както всяко друго повикване към вашия ключ. Ще го видите в activity log-а си с правилния outcome етикет (success, client_error, application_error, rate_limit, service_error). Полезно за repro на нестабилно production повикване: пуснете го отново в Playground, намерете го в activity log-а и споделете линка с екипа.

What's Next

Playground е първата стъпка от по-голям стремеж да направим така, че Dashboard да прави повече от това просто да показва какво вече сте направили. Моделите, които виждаме в request log-а, оформят това, което ще пуснем следващо.

Ако го използвате днес и нещо ви се струва нередно, поле, което не съвпада с документацията, cookie, което не е оцеляло след redirect, или response, който се рендерира грешно, това е обратната връзка, която четем първо. Dashboard вижда requests. Ние виждаме тенденциите.