← Tất cả bài viết
Cập nhật sản phẩm 7 phút đọc

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

Khai báo các response được tính là thành công bằng cách sử dụng các quy tắc validate. Các response không phải 200 được bạn chấp nhận giờ đây sẽ được tính phí chính xác và hiển thị là thành công trong nguồn cấp dữ liệu Activity của bạn.

apivalidationoutcomesbilling

Các quy tắc validate của request giờ đây sẽ định hướng cách phân loại mọi kết quả. Chỉ cần khai báo mã 403 là có thể chấp nhận được, và một response 403 được trả về sẽ được tính là thành công, tính phí là thành công, và xuất hiện trong nguồn cấp dữ liệu Activity bên cạnh các response 200 của bạn.

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

Cách hoạt động

Mỗi request gửi đến FourA sẽ nhận được một trong bảy kết quả quyết định việc tính phí và phân tích dữ liệu. Chỉ có success mới bị tính phí. Các kết quả còn lại được phân chia dựa trên việc bên nào chịu trách nhiệm cho lỗi đó:

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

Trước thay đổi này, thành công chỉ có duy nhất một ý nghĩa: HTTP 200. Mã 403 luôn được coi là application_fail, ngay cả khi bạn biết rằng 403 chính là response mà bạn mong muố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à đó chính là tín hiệu mà code của bạn đang chờ đợi.)

Giờ đây, block validate của bạn sẽ quyết định điều đó. Request sẽ chạy các quy tắc của bạn trong quá trình thực thi. Nếu response đáp ứng các quy tắc này, kết quả sẽ là success.

curl -X POST "https://eu.api.foura.ai/v1/request" \
  -H "Authorization: Bearer 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"] }
    }
  }'

Cấu hình này coi 200 và 403 là các status code hợp lệ. Nếu body chứa dấu hiệu CAPTCHA hoặc chuỗi thông báo từ chối truy cập (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 ghi nhớ:

  1. Nếu không có validate, hành vi sẽ không thay đổi. Các request không khai báo validation vẫn chỉ tính phí dựa trên HTTP 200. Bạn chủ động chọn sử dụng.
  2. validate hoạt động theo cả hai chiều. Các quy tắc chấp nhận (accept) sẽ cho qua; các quy tắc thất bại (fail) sẽ từ chối. Chúng kết hợp với nhau. Vì vậy, 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 mong muốn.

Tác động

Sự thay đổi này có ý nghĩa quan trọng nhất đối với các đội ngũ có trang web mục tiêu trả về các response không phải 200 nhưng họ thực sự cần.

Các ví dụ từ những request chúng tôi thấy hàng ngày:

  • Các API dữ liệu thể thao trả về 403 cho 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)
  • Các endpoint tìm kiếm thương mại điện tử trả về 404 khi một SKU hết hàng (một tín hiệu mà code của bạn cần đọc, không phải là một lỗi)
  • Các API streaming và partial-content trả về 206

Trước khi có thay đổi này, các đội ngũ đó phải tự thực hiện việc đối soát dữ liệu riêng dựa trên Activity log của chúng tôi. Họ không thể tin tưởng cột outcome vì định nghĩa về thành công của họ không khớp với định nghĩa của 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.

Giờ đây, cột này phản ánh đúng thực tế. Tab Activity trong Dashboard của bạn sẽ hiển thị những gì bạn đã định nghĩa là thành công, chứ không phải những gì chúng tôi tự suy đoán. Tổng chi phí bị tính sẽ khớp với những gì bạn tự thống kê (kết quả ban đầu: thay đổi này chỉ áp dụng cho các dữ liệu mới phát sinh, vì vậy các dò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 một 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 đã thực hiện việc validation trên response body sau khi nhận dữ liệu, bạn có thể chuyển giao ước đó vào chính request và ngừng duy trì một tập hợp các quy tắc thành công/thất bại song song bên ngoài API của chúng tôi. Chỉ cần một định nghĩa duy nhất để xác định xem một request có xứng đáng nằm trong tập dữ liệu của bạn hay không, thay vì hai định nghĩa không thống nhất.

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

Dành cho Power User

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

curl -X POST "https://eu.api.foura.ai/v1/request" \
  -H "Authorization: Bearer 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"] }
    }
  }'

Cấu hình 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 bẫy captcha

Nếu bất kỳ quy tắc nào thất bại, kết quả sẽ là application_fail. Nếu mọi thứ đều vượt qua, kết quả sẽ là success. Trình phân loại chạy ngay bên trong chính request, vì vậy bạn có thể bỏ qua độ trễ round-trip mà một bước validation riêng biệt thường tiêu tốn.

Khi kết hợp với followRedirects: theo dõi tối gia năm hop, sau đó validate response cuối cùng. Một chiêu trò đánh tráo (bait-and-switch) từ một URL sạch sang một cổng CAPTCHA sẽ thất bại một cách rõ ràng thay vì làm bẩn tập dữ liệu của bạn.

Và một mẹo nhỏ từ việc vận hành các scraper của chính chúng tôi: hãy khai báo các pattern data.fail một cách triệt để. Một phản hồi 200 OK chứa CAPTCHA bên trong là lỗi ngầm (silent failure) phổ biến nhất trên các trang web được bảo vệ. Hãy coi body là nguồn đáng tin cậy nhất, chứ không phải status code.

Để xem schema đầy đủ, tài liệu tham khảo request liệt kê mọi trường validate và cách kết hợp từng trườ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: các bộ khớp regex cho data, các biểu thức điều kiện JSON-path có cấu trúc, và việc khớp header linh hoạt hơn. Nguyên tắc vẫn giữ nguyên. Bạn khai báo định nghĩa về thành công; API sẽ tuân thủ định nghĩa đó từ đầu đến cuối, từ request cho đến hóa đơn của bạn.

Khi scraper của bạn gặp lỗi, nó cần phải báo lỗi một cách rõ ràng. Và khi nó hoạt động dựa trên các quy tắc do chính bạn viết ra, đó là một con số mà bạn thực sự có thể tin tưởng.