Playground hiện đã hoạt động trong Dashboard của bạn. Ba endpoint, một cookie jar, mọi header đều được phân tích cú pháp. Chọn Single, Proxy, hoặc Browser, điền thông tin request, nhấn Send. Response sẽ hiển thị ngay trên cùng một màn hình với status, headers, body, và các cookie đã được phân tích cú pháp. Khi bạn đã hài lòng, hãy sao chép lệnh curl hoạt động tốt vào mã nguồn của mình.
Đây không phải là một trang riêng biệt hay một sandbox nằm sau một URL khác. Nó chạy trực tiếp với API thực tế bằng key thật của bạn. Những gì bạn thấy trong Playground chính là những gì mã nguồn production của bạn sẽ nhận về.
Cách thức hoạt động
Bạn đăng nhập vào Dashboard, chọn một trong ba endpoint, và biểu mẫu sẽ tự động thay đổi để chỉ hiển thị các trường mà endpoint đó thực sự chấp nhận.
- Single nhận
url,method,headers,unblocker,proxy,tryJsonData,followRedirects, và nhóm timeout. - Proxy nhận cùng một tập hợp đó được bọc trong một block
request, cộng thêm các bộ lọc chọn proxy (quốc gia, thành phố, ASN, mức độ ẩn danh, freshness). - Browser nhận
url,cookies,headers, và các điều kiện chờ.
Khi bạn nhấn Send, Dashboard sẽ xác thực cuộc gọi với tài khoản của bạn và gửi yêu cầu POST đến /api/{endpoint} trên api.foura.ai. API key thực tế của bạn không bao giờ truyền qua trang web. Playground là nơi duy nhất trong Dashboard mà bạn có thể thực hiện một request tính phí mà không làm lộ key trong trình duyệt.
Hây đây là lệnh curl tái tạo mà Playground tạo ra cho một request Single cơ bản:
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
}'
Hãy dán lệnh đó vào terminal hoặc script build và nó sẽ hoạt động chính xác như nút Send. Chúng tôi không bọc payload trong một cấu trúc tùy chỉnh nào hay đổi tên bất kỳ trường nào. Playground gửi chính xác những gì API tiếp nhận, không hơn không kém.
Kết quả nhận về
Bảng điều khiển response hiển thị status từ upstream, tổng thời gian, và (đối với các cuộc gọi Proxy) proxy id đã xử lý request. Body, Headers, và Cookies mỗi phần đều có tab riêng.
Body. JSON tự động phát hiện sẽ hiển thị trong trình xem có thể thu gọn. Payload HTML chuyển sang khung xem trước để bạn có thể dễ dàng kiểm tra những gì trang web mục tiêu trả về. Văn bản thuần túy được chuyển về chế độ xem monospace đơn giản. Có một hộp tìm kiếm trên Body và Raw hỗ trợ chuyển nhanh giữa kết quả trước/sau.
Headers. Chế độ xem đã phân tích cú pháp với mỗi dòng cho một cặp name: value, hoặc Raw cho toàn bộ chuỗi response multi-hop. Mỗi lần redirect đều để lại tập hợp header riêng, vì vậy việc theo dấu một mã 302 đến đích cuối cùng chỉ mất một cú nhấp chuột.
Cookies. Cookie jar phân tích cú pháp mọi dòng Set-Cookie từ response, theo dõi xem mỗi cookie là host-only hay domain-wide (RFC 6265 §5.3), và cung cấp hai chế độ xem: các thẻ có thể thu gọn theo từng host hoặc danh sách raw. Bật cookie jar và request tiếp theo sẽ tự động kéo các cookie khớp vào. Đối với Single và Proxy, điều đó có nghĩa là một header Cookie trên request gửi đi. Đối với Browser, điều đó có nghĩa là một mảng cookie được đính kèm vào đối tượng request.
Preset lưu toàn bộ cấu hình request dưới một tên gọi và mô tả, nhờ đó bạn có thể nhanh chóng quay lại "test login on staging" mà không cần thiết lập lại từ đầu. History lưu giữ hai mươi lượt chạy gần nhất của bạn với status, content type, tổng thời gian, và proxy đã sử dụng.
Tác động
Điều mà Playground thực sự thay đổi chính là vòng lặp thử nghiệm.
Trước đây, bạn phải viết một script nhỏ (Node, Python, hoặc shell), cấu hình key, gọi API, in ra body, tinh chỉnh một header, rồi chạy lại. Có thể mất mười phút từ lúc tự hỏi "không biết trang web này trả về cái gì" cho đến khi có câu trả lời.
Trong Playground, vòng lặp đó rút ngắn xuống còn khoảng mười lăm giây. Nhấp vào endpoint, dán URL, nhấn Send, xem cookie, chuyển unblocker từ off sang on, nhấn Send lần nữa. Vào lúc bạn chuẩn bị mở trình soạn thảo mã nguồn của mình, bạn đã biết phiên bản request nào hoạt động tốt trên mục tiêu.
Chúng tôi không ra mắt Playground để thay thế mã nguồn thực tế của bạn. Chúng tôi ra mắt nó để con đường từ "liệu việc này có khả thi trên trang web này không" đến "có, đây là lệnh curl hoạt động tốt" không còn cần đến một dự án phụ nữa.
Dành cho Power User
Một vài điểm không dễ nhận thấy ngay từ giao diện bên ngoài:
Preset mang theo toàn bộ payload. Điều đó bao gồm nhóm timeout, các quy tắc xác thực, giới hạn redirect, và bất kỳ custom header nào. Khi bạn lưu một preset, bạn đang chụp lại trạng thái của một request đã được thử nghiệm, chứ không chỉ riêng URL. Điều này rất hữu ích khi bạn duy trì một tập hợp các smoke test ổn định trên các endpoint.
Cookie jar hoạt động theo từng session. Nó nằm trong trình duyệt của bạn. Chúng tôi không lưu trữ lâu dài các cookie thu thập được ở phía server. Hãy tải lại trang nếu bạn cần một trạng thái sạch.
Tab Raw và biểu mẫu luôn đồng bộ với nhau. Các trường trong biểu mẫu hiển thị cùng một JSON mà tab Raw hiển thị. Dán một payload vào Raw và biểu mẫu sẽ tự động điền lại. Nhờ đó, đồng nghiệp có thể gửi một request đang hoạt động tốt vào khung chat, bạn dán nó vào Raw, và biểu mẫu sẽ tự động điền đầy đủ.
Cookie của Browser có dạng đối tượng, không phải dạng header. Nếu bạn gửi cookie đến endpoint Browser một cách thủ công, mỗi mục nhập sẽ nhận {name, value, domain?, path?, httpOnly?, secure?, sameSite?}. Playground sẽ xây dựng chúng một cách chính xác khi cookie jar được bật. Nếu bạn tự tạo chúng, việc khớp schema là rất quan trọng.
Outcome hiển thị trong activity feed của bạn. Khi Playground thực hiện một request, nó được tính giống như bất kỳ cuộc gọi nào khác đối với key của bạn. Bạn sẽ thấy nó trong activity log của mình với nhãn outcome chính xác (success, client_error, application_error, rate_limit, service_error). Rất hữu ích để tái tạo lỗi cho một cuộc gọi production chập chờn: chạy lại nó trong Playground, tìm nó trong activity log, và chia sẻ liên kết đó với đội ngũ của bạn.
Kế hoạch tiếp theo
Playground là bước đầu tiên trong một nỗ lực lớn hơn nhằm giúp Dashboard làm được nhiều việc hơn là chỉ hiển thị những gì bạn đã thực hiện. Các mô hình mà chúng tôi thấy trong request log sẽ định hình những tính năng được ra mắt tiếp theo.
Nếu bạn đang sử dụng nó hôm nay và cảm thấy có gì đó không ổn, một trường không khớp với tài liệu hướng dẫn, một cookie không tồn tại sau khi redirect, một response hiển thị sai, đó chính là những phản hồi mà chúng tôi ưu tiên đọc trước tiên. Dashboard nhìn thấy các request. Chúng tôi nhìn thấy các xu hướng.