Highlights
Giờ đây, bạn có thể nhấp vào bất kỳ request nào trong Activity để xem toàn bộ payload. Chỉ cần thêm một cú nhấp chuột để mở lại request đó trong Playground, được điền sẵn dữ liệu và sẵn sàng chạy lại. Chúng tôi cũng đã phát hiện một loại "proxy" chuyên phản hồi ngược lại chính request của bạn dưới dạng một response giả mạo, và đã ngăn chặn nó làm sai lệch dữ liệu của bạn.
What's New
Activity → Playground: chạy lại bất kỳ request nào
Mỗi cuộc gọi API đều trả về một header X-Foura-Request-Id. ID tương tự cũng xuất hiện bên cạnh request trong Activity. Nhấp vào bất kỳ hàng nào để xem bức tranh toàn cảnh: thời điểm chạy, key nào đã thực hiện, request body, response, các status code, và thời gian xử lý. Nhấp vào "Open in Playground" và request sẽ được tải vào biểu mẫu, điền sẵn dữ liệu.
Trước đây, việc chạy lại (replay) đồng nghĩa với việc phải tự dựng lại request từ trí nhớ. Giờ đây, Activity lưu trữ lịch sử, và Playground đóng vai trò là nút chạy lại.
Một vài cơ chế cần lưu ý. Chúng tôi lưu trữ 200 payload gần nhất cho mỗi API key trong vòng 24 giờ. Sau đó, các bản ghi cũ hơn sẽ bị ghi đè khi có bản ghi mới. Khi một payload đã hết hạn, hộp thoại sẽ thông báo cho bạn, thay vì hiển thị giá trị null gây bối rối hoặc "(empty body)" như trước đây.
Bạn cũng có thể đối chiếu request id một cách dễ dàng. Hãy ghi log response header X-Foura-Request-Id bên cạnh request id của riêng bạn ở phía client, và việc tìm kiếm hàng Activity tương ứng sau này chỉ mất một thao tác dán.
Quá trình ghi nhận (capture) nằm ngoài hot path. Request API của bạn không bao giờ phải chờ đợi quá trình này. Và nếu capture store không thể truy cập, cuộc gọi vẫn được thực hiện bình thường; hộp thoại sẽ chỉ hiển thị "no body captured" sau đó.
Validate dựa trên response body
Mục Validate của Playground đã được bổ sung các quy tắc kiểm tra nội dung body. Bạn có thể thiết lập "chỉ thành công nếu response chứa X", hoặc "thất bại nếu chứa Y", với nhiều tùy chọn khác nhau được phân tách bằng dấu |. Tính năng này hoạt động cho cả Single và Proxy. Rất hữu ích khi các status code không phản ánh đúng những gì thực sự xảy ra.
Các payload không có body tự giải thích rõ ràng hơn
Các request thất bại không có response body để hiển thị. Hộp thoại cũ hiển thị trường hợp đó là null hoặc "(empty body)", rất dễ bị hiểu nhầm là một response trống thực sự. Hộp thoại hiện tại phân biệt rõ ba trường hợp: request thất bại (với thông báo lỗi thực tế), không có payload nào được ghi nhận, hoặc máy chủ thực sự trả về zero byte.
Một cải tiến nhỏ, nhưng loại bỏ được sự băn khoăn thường gặp: "khoan đã, đó là response thực tế hay là lỗi giao diện?".
Nút Reset trong Playground
Đưa biểu mẫu của endpoint đang hoạt động về trạng thái mặc định chỉ với một cú nhấp chuột. Các thiết lập mặc định vẫn giữ unblocker và tryJsonData ở trạng thái bật, vì đó là luồng xử lý phổ biến trong 90% trường hợp.
Under the Hood
Phát hiện honeypot proxy
Một số "proxy" hoạt động thực tế không hề chuyển tiếp request. Chúng phản hồi ngược lại chính request của bạn dưới dạng một bản dump các biến máy chủ (server-variables dump) dạng văn bản thuần túy (gồm HTTP method, các header, target host) để quản trị viên của chúng có thể thu thập bất kỳ dữ liệu nào bên trong đó. Chúng tôi đã thấy cùng một proxy chuyển tiếp một request, phản hồi ngược lại request tiếp theo, và trả về lỗi 502 ở request sau đó, tất cả chỉ trong một session duy nhất.
Trình kiểm tra body (body validator) hiện tại sẽ phát hiện chữ ký của bản dump này trước khi response rời khỏi edge của chúng tôi. Single sẽ trả về một lỗi trung thực. Proxy Finder sẽ thử lại với một proxy khác. Browser kế thừa cùng một cơ chế bảo vệ từ lớp HTTP dùng chung. Nhờ đó, bạn sẽ thấy ít hàng rác hơn trong Activity, và các scraper của bạn sẽ không thu thập những thứ trông giống như dữ liệu nhưng thực chất lại là một cuộc thăm dò.
Hiện tại chưa có thay đổi nào về điểm uy tín (reputation). Proxy đó tạm thời vẫn nằm trong pool. Chúng tôi chỉ từ chối trả về phản hồi giả mạo của nó cho bạn.
Vì vậy, nếu một request xuất hiện trong Activity và bị gắn nhãn là thất bại hoàn toàn (hard failure) thay vì trông có vẻ "thành công" như trước đây, thì đó chính là do trình bảo vệ đã chặn nó lại. Thà nhận một lỗi rõ ràng còn hơn là một bản ghi bị nhiễm độc.