리다이렉트 체인은 스크래퍼를 중단시킵니다. 바이너리 응답은 텍스트로 디코딩될 때 손상됩니다. "페이지 가져오기, HTML 파싱하기" 단계를 지나면 끊임없이 발생하는 두 가지 문제입니다.
이 두 문제를 처리하기 위해 두 가지 새로운 request 옵션인 followRedirects 및 returnBuffer를 출시했습니다. 지금 API에 적용되었습니다.
작동 방식
followRedirects를 활용한 리다이렉트 제어
대부분의 스크래핑 API는 리다이렉트를 boolean 값으로 처리합니다(따라가거나, 따라가지 않거나). 이는 리다이렉트 체인이 루프를 돌거나, 트래킹 파라미터를 추출하기 위해 중간 302 response 자체가 필요해지기 전까지만 유효합니다.
FourA의 followRedirects는 0에서 20 사이의 정수를 받습니다. 값을 생략하거나 0으로 설정하면 헤더를 포함한 원본 리다이렉트 response를 그대로 반환합니다. 5로 설정하면 request가 최대 5개의 홉까지 따라간 후 최종 도달한 결과를 반환합니다.
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/short-link",
"followRedirects": 3,
"unblocker": true
}'
최대 3개의 리디렉션을 따릅니다. 체인이 2개 내에서 완료되면 최종 페이지를 수신합니다. 3개보다 길면 세 번째 홉이 반환한 결과를 그대로 받습니다.
이 차이는 생각보다 중요합니다. 이커머스 사이트는 제품 페이지에 도달하기 전에 트래킹 URL을 거쳐 리디렉션됩니다. 이러한 리디렉션은 따라가야 합니다. 하지만 제휴 네트워크나 URL 단축기는 6, 7, 8홉 깊이까지 이어지는 체인을 생성하기도 합니다. 일부 리디렉션 루프는 전혀 해결되지 않습니다. 특정 횟수로 제한하면 request timeout을 소진하는 무한 루프에 빠지지 않고 데이터를 수집할 수 있습니다.
이전의 해결 방법은 리디렉션을 비활성화한 상태로 request를 보내고, Location 헤더를 수동으로 파싱한 뒤 다른 request를 보내는 것이었습니다. 최소 두 번의 API 호출과 두 배의 지연 시간, 그리고 직접 관리해야 하는 코드가 발생했습니다. 이제는 숫자 하나를 지정한 단일 호출로 처리할 수 있습니다.
Raw Binary Responses with returnBuffer
이미지, PDF 또는 protobuf 페이로드를 수집할 때 텍스트 디코딩은 데이터를 손상시킵니다. HTTP 라이브러리가 response를 텍스트로 간주하고 charset 감지를 적용하여 맞지 않는 모든 바이트를 조용히 훼손합니다. Protobuf는 읽을 수 없게 됩니다. 이미지 헤더가 손상됩니다. 명확한 오류 메시지도 없이 파일이 깨지는 결과를 초래합니다.
returnBuffer는 API에 텍스트 디코딩을 완전히 건너뛰도록 지시합니다.
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-image.jpg",
"returnBuffer": true
}'
response body는 원시 바이트(JSON response에서는 base64 인코딩) 형태로 반환됩니다. 클라이언트에서 디코딩하면 서버가 보낸 원본 그대로를 얻을 수 있습니다. 문자셋 추측이나 인코딩 변환이 없으며, 알 수 없는 데이터 손상도 발생하지 않습니다.
이는 가장 자주 접수되었던 지원 티켓 중 하나였습니다. 사용자가 제품 이미지나 PDF 카탈로그를 수집할 때 파일이 열리지 않는 문제가 발생하곤 했습니다. 해결 방법은 늘 동일했지만, 이제 임시방편 대신 전용 플래그가 제공됩니다.
영향
두 기능 모두 작업당 API 호출 수를 줄여줍니다. followRedirects은 수동 redirect 추적 루프를 제거합니다. returnBuffer는 "데이터 가져오기, 손상 확인, 다른 설정으로 다시 가져오기"의 반복을 없앱니다.
redirect가 많은 대상(제휴 링크, 단축 URL, 이커머스 추적 체인)의 경우, 사용자가 수동 redirect 처리에서 followRedirects(으)로 전환했을 때 초기 테스트에서 request 수가 40-60% 감소하는 것을 확인했습니다. 바이너리 수집 작업(제품 이미지, 문서 다운로드)의 경우, returnBuffer을(를) 통해 여러 단계의 우회 방식이 단일 옵션으로 단순화되었습니다(초기 결과).
화려한 기능은 아닙니다. 하지만 새벽 3시에 사이트 결제 흐름에 redirect hop이 하나 더 추가되어 scraper가 중단되기 전까지는 미처 생각하지 못하는 중요한 기능입니다.
고급 사용자를 위한 팁
followRedirects을(를) response 검증과 결합하여 redirect 체인을 정밀하게 제어할 수 있습니다. redirect를 추적하되, 최종 목적지에서 문제가 발생하면 request를 실패 처리하도록 설정할 수 있습니다.
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/12345",
"followRedirects": 5,
"unblocker": true,
"validate": {
"status": { "fail": [403, 503] },
"data": { "fail": ["Access Denied", "captcha"] }
}
}'
이 설정은 최대 5회의 redirect를 추적한 뒤 최종 response를 확인합니다. 사이트가 인증 페이지나 접근 차단 화면으로 redirect한 경우, request는 깔끔하게 실패 처리됩니다. 다운스트림에서 불필요한 데이터를 걸러낼 필요가 없습니다.
바이너리 수집의 경우, 대용량 파일을 다운로드하기 전에 content type을 확인해야 한다면 returnBuffer와 HEAD request를 함께 사용하십시오. FourA는 HEAD를 올바르게 처리하므로 body를 가져오지 않고도 header를 검사할 수 있습니다. Content-Type을 확인하고 다운로드할 가치가 있는지 판단한 뒤, returnBuffer: true를 사용하여 전체 request를 실행하십시오.
JavaScript 사용량이 많은 타깃을 위해 브라우저 작업을 사용하는 경우, 해당 옵션들은 direct HTTP 엔진에 적용된다는 점에 유의하십시오. 브라우저 request는 브라우저 내장 탐색 기능을 통해 redirect를 처리하며, 기본적으로 제한 없이 redirect를 추적합니다.
향후 계획
API를 통해 커스텀 DNS 확인, 단계별 timeout 조정, 인증서 처리 옵션 등 더 많은 request 수준의 제어 기능을 제공하기 위해 작업 중입니다. 목표는 인프라 오버헤드 없이 깔끔한 REST 인터페이스를 통해 브라우저 프로필을 완벽하게 제어할 수 있도록 지원하는 것입니다.
필요한 특정 옵션이 있다면 언제든 의견을 보내주십시오. 대시보드에서 이러한 새 옵션이 적용된 request의 성능을 이미 확인할 수 있으므로, 차이를 직접 측정해보실 수 있습니다.