Quy tắc validate giờ đây quyết định những gì được tính là thành công

Các quy tắc validate trong request của bạn hiện quyết định cách phân loại mọi kết quả. Khai báo mã 403 là chấp nhận được, và mã 403 được trả về sẽ tính là thành công, tính phí như thành công, và xuất hiện trong Activity feed cùng với các mã 200 của bạn.

Điều này nghe có vẻ nhỏ. Nhưng nó thay đổi cách bạn đo lường độ chính xác khi scraping ở quy mô lớn.

Cơ chế hoạt động

Mỗi request đến FourA nhận một trong bảy kết quả dùng để quyết định việc tính phí và phân tích. Chỉ success là bị tính phí. Các kết quả còn lại phân chia theo bên chịu trách nhiệm cho lỗi:

application_fail và application_error khi trang web đích từ chối hoặc trả về nội dung lỗi
client_error khi request bạn gửi bị sai định dạng
service_fail, service_error, và rate_limit khi có lỗi từ phía chúng tôi chặn request

Trước thay đổi này, thành công chỉ có đúng một nghĩa: HTTP 200. Mã 403 luôn là application_fail, ngay cả khi bạn biết mã 403 đó chính là response bạn cần. (Một số API dữ liệu thể thao trả về 403 cho các thị trường bị giới hạn địa lý, và đó là tín hiệu mà code của bạn đang chờ.)

Hiện tại khối validate của bạn sẽ quyết định. Request chạy các quy tắc của bạn trong quá trình thực thi. Nếu response thỏa mãn các quy tắc đó, kết quả là success.

curl -X POST "https://eu.api.foura.ai/v1/request" \
  -H "X-API-Key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "url": "https://example.com/api/feed",
    "unblocker": true,
    "validate": {
      "status": { "accept": [200, 403] },
      "data": { "fail": ["captcha", "Access Denied"] }
    }
  }'

Thiết lập này xử lý mã trạng thái 200 và 403 là hợp lệ. Nếu body chứa dấu hiệu trang xác minh hoặc chuỗi access-denied, request sẽ thất bại. Mọi trường hợp khác đều là success.

Hai quy tắc cần nhớ:

Nếu không có validate, hành vi không đổi. Các request không khai báo validation vẫn chỉ tính phí trên HTTP 200. Bạn tự chọn tham gia.
validate hoạt động theo cả hai chiều. Quy tắc accept sẽ cho qua; quy tắc fail sẽ từ chối. Chúng kết hợp với nhau. Do đó bạn có thể chấp nhận [200, 403] nhưng vẫn đánh dấu thất bại khi body chứa nội dung không đúng.

Tác động

Thay đổi này quan trọng nhất đối với các nhóm có mục tiêu trả về phản hồi non-200 mà họ thực sự cần.

Ví dụ từ các request chúng tôi thấy hàng ngày:

API dữ liệu thể thao trả về 403 đối với các thị trường bị giới hạn địa lý (vẫn là dữ liệu hữu ích, vẫn đáng để ghi nhận là thành công)
Endpoint tìm kiếm thương mại điện tử trả về 404 khi một SKU hết hàng (tín hiệu mà mã nguồn của bạn đọc được, không phải lỗi)
API phát trực tuyến và nội dung một phần trả về 206

Trước thay đổi này, các nhóm đó phải tự theo dõi đối soát song song với nhật ký Activity của chúng tôi. Họ không thể tin tưởng cột outcome vì định nghĩa thành công của họ không khớp với chúng tôi. Họ bị tính phí dựa trên một con số mà họ không thực sự quan tâm.

Bây giờ cột này phản ánh đúng thực tế. Tab Activity trong Dashboard của bạn hiển thị những gì bạn đã định nghĩa là thành công, không phải những gì chúng tôi phỏng đoán. Tổng số tiền tính phí khớp với những gì bạn tự đếm (kết quả ban đầu: thay đổi chỉ áp dụng cho dữ liệu mới trở đi, vì vậy các hàng Activity cũ hơn vẫn giữ nguyên phân loại ban đầu).

Hiệu quả thực tế đối với tác vụ scraping: giảm bớt các bước đối soát giữa pipeline của bạn và hóa đơn của chúng tôi. Nếu bạn đã chạy validation trên response body sau khi nhận dữ liệu, bạn có thể chuyển thỏa thuận đó vào chính request và ngừng duy trì một bộ quy tắc pass/fail song song bên ngoài API của chúng tôi. Một định nghĩa duy nhất về việc liệu một request có hợp lệ để đưa vào tập dữ liệu của bạn hay không, thay vì hai định nghĩa mâu thuẫn nhau.

Nhưng chúng tôi vẫn giữ cơ chế an toàn. Nếu bạn không truyền khối validate, không có gì thay đổi. Trình phân loại sẽ mặc định quay về "200 nghĩa là thành công" để các request đã hoạt động hôm qua vẫn hoạt động theo cách tương tự hôm nay.

Dành cho người dùng nâng cao

validate chấp nhận ba bộ quy tắc chạy độc lập: status, headers và data. Mỗi bộ chấp nhận các danh sách tùy chọn accept và fail.

curl -X POST "https://eu.api.foura.ai/v1/request" \
  -H "X-API-Key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "url": "https://example.com/product/9876",
    "followRedirects": 5,
    "unblocker": true,
    "validate": {
      "status": { "accept": [200, 304] },
      "headers": { "accept": { "content-type": "application/json" } },
      "data": { "accept": ["\"price\":"], "fail": ["maintenance", "captcha"] }
    }
  }'

Điều này yêu cầu:

Status là 200 hoặc 304
Response khai báo content type là JSON
Body chứa trường price
Body không chứa thông báo bảo trì hoặc trang xác minh

Nếu bất kỳ quy tắc nào thất bại, kết quả là application_fail. Nếu mọi thứ đều đạt, kết quả là success. Bộ phân loại chạy ngay bên trong chính request, giúp bạn bỏ qua độ trễ round trip của một bước xác thực riêng biệt.

Kết hợp với followRedirects: theo dõi tối đa năm hop, sau đó xác thực response cuối cùng. Việc bị chuyển hướng ngầm từ một URL sạch sang trang xác minh sẽ báo lỗi rõ ràng thay vì làm bẩn tập dữ liệu của bạn.

Một kinh nghiệm từ việc vận hành scraper của chính chúng tôi: hãy khai báo các mẫu data.fail một cách triệt để. Mã 200 OK nhưng chứa trang xác minh bên trong là dạng lỗi ngầm phổ biến nhất trên các trang web có hệ thống bảo vệ. Hãy coi body là nguồn chuẩn xác, không phải status code.

Để xem đầy đủ schema, tài liệu tham khảo request liệt kê từng trường validate và cách kết hợp chúng.

Bước tiếp theo

Chúng tôi đang phát triển các thành phần quy tắc phong phú hơn: regex matcher cho data, predicate JSON-path có cấu trúc, và khớp header linh hoạt hơn. Nguyên tắc vẫn không đổi. Bạn định nghĩa thế nào là thành công; API sẽ đảm bảo điều đó xuyên suốt từ request cho đến hóa đơn thanh toán của bạn.

Khi scraper gặp sự cố, nó cần phải báo lỗi rõ ràng. Và khi nó hoạt động theo đúng các quy tắc do chính bạn viết, đó là con số bạn hoàn toàn có thể tin cậy.