전체 글

Redirect 제어 및 Raw Buffer 모드

FourA의 API가 이제 설정 가능한 redirect 제한과 raw binary response를 지원합니다. 실제 스크래핑 edge case를 처리하는 방식을 바꿔줄 두 가지 옵션입니다.

Redirect 체인은 스크래퍼를 중단시킵니다. 바이너리 response는 텍스트로 디코딩될 때 손상됩니다. "페이지를 가져와 HTML을 파싱하는" 단계를 넘어서면 끊임없이 발생하는 두 가지 문제입니다.

이 두 가지를 모두 처리하기 위해 두 개의 새로운 request 옵션인 followRedirectsreturnBuffer를 출시했습니다. 현재 API에 적용되어 있습니다.

작동 방식

followRedirects를 사용한 Redirect 제어

대부분의 스크래핑 API는 redirect를 boolean 값으로 처리합니다. 즉, 추적하거나 추적하지 않거나 둘 중 하나입니다. 하지만 루프를 도는 redirect 체인을 만나거나, 추적 파라미터를 추출하기 위해 중간 302 response 자체가 필요한 경우에는 이 방식이 작동하지 않습니다.

FourA의 followRedirects는 0에서 20 사이의 정수를 받습니다. 이 값을 생략하거나 0으로 설정하면 header를 포함한 raw redirect response를 그대로 돌려받습니다. 5로 설정하면 request가 최대 5번의 홉을 추적한 후 최종 도달한 결과를 반환합니다.

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/short-link",
    "followRedirects": 3,
    "unblocker": true
  }'

이것은 최대 3번의 redirect를 추적합니다. 체인이 2번 만에 해결되면 최종 페이지를 받게 됩니다. 3번보다 길면 세 번째 홉이 반환한 결과를 받게 됩니다.

이 차이는 생각보다 중요합니다. 이커머스 사이트는 상품 페이지에 도달하기 전에 추적 URL을 통해 redirect합니다. 이러한 redirect는 추적해야 합니다. 하지만 제휴 네트워크와 URL 단축 서비스는 때로 6단계, 7단계, 8단계 깊이까지 들어가는 체인을 생성합니다. 그리고 일부 redirect 루프는 결코 해결되지 않습니다. 특정 숫자로 제한을 두면 request 타임아웃을 소모하는 무한 루프에 빠지지 않고 데이터를 수집할 수 있습니다.

이전에는 redirect를 비활성화한 상태로 request를 보내고, Location header를 수동으로 파싱한 다음, 다른 request를 보내는 방식으로 우회해야 했습니다. 이는 최소 두 번의 API 호출, 두 배의 지연 시간, 그리고 직접 유지 관리해야 하는 코드를 의미했습니다. 이제는 숫자 하나만 지정하여 단 한 번의 호출로 해결할 수 있습니다.

returnBuffer를 사용한 Raw Binary Response

이미지, PDF 또는 protobuf 페이로드를 수집할 때 텍스트 디코딩은 데이터를 파괴합니다. HTTP 라이브러리는 response를 텍스트로 가정하고, 캐릭터셋 감지를 적용하며, 맞지 않는 모든 바이트를 자동으로 손상시킵니다. Protobuf는 읽을 수 없게 됩니다. 이미지 header가 깨집니다. 결국 파일이 손상되고, 그 이유를 설명하는 명확한 에러 메시지도 받지 못하게 됩니다.

returnBuffer는 API에 텍스트 디코딩을 완전히 건너뛰도록 지시합니다.

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-image.jpg",
    "returnBuffer": true
  }'

response body는 raw 바이트(JSON response에서는 base64로 인코딩됨)로 반환됩니다. 수신 측에서 이를 디코딩하면 서버가 보낸 것과 정확히 일치하는 데이터를 얻을 수 있습니다. 캐릭터셋 가정도, 인코딩 변환도, 소리 없는 데이터 손상도 없습니다.

이는 저희가 가장 자주 접했던 지원 티켓 중 하나였습니다. 사용자가 상품 이미지나 PDF 카탈로그를 수집할 때 열리지 않는 파일이 생성되는 문제였습니다. 해결책은 항상 동일했지만, 이제는 우회 방법 대신 이를 위한 플래그가 제공됩니다.

영향

두 기능 모두 작업당 API 호출 횟수를 줄여줍니다. followRedirects는 수동으로 redirect를 추적하는 루프를 제거합니다. returnBuffer는 "가져오고, 손상된 것을 확인하고, 다른 설정으로 다시 가져오는" 순환을 제거합니다.

redirect가 많은 대상(제휴 링크, URL 단축 서비스, 이커머스 추적 체인)의 경우, 초기 테스트에서 사용자가 수동 redirect 처리에서 followRedirects로 전환했을 때 request 수가 40-60% 감소하는 것을 확인했습니다. 그리고 바이너리 수집 작업(상품 이미지, 문서 다운로드)의 경우, returnBuffer는 여러 단계의 우회 과정을 단일 옵션으로 바꾸어 줍니다(초기 결과).

이것들은 화려한 기능이 아닙니다. 어떤 사이트가 결제 흐름에 redirect 홉을 하나 더 추가하는 바람에 새벽 3시에 스크래퍼가 작동을 멈추기 전까지는 생각조차 하지 않을 그런 종류의 기능입니다.

파워 유저를 위한 기능

redirect 체인을 정밀하게 제어하려면 followRedirects를 response 검증과 결합하십시오. redirect를 추적하되, 최종 목적지가 장벽에 부딪히면 request를 실패 처리합니다.

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/12345",
    "followRedirects": 5,
    "unblocker": true,
    "validate": {
      "status": { "fail": [403, 503] },
      "data": { "fail": ["Access Denied", "captcha"] }
    }
  }'

이것은 최대 5번의 redirect를 추적한 다음 최종 response를 확인합니다. 사이트가 귀하를 CAPTCHA 페이지나 액세스 거부 장벽으로 redirect한 경우, request는 깔끔하게 실패합니다. 다운스트림에서 필터링해야 할 가비지 데이터가 남지 않습니다.

바이너리 수집의 경우, 대용량 파일을 다운로드하기 전에 콘텐츠 유형을 확인해야 한다면 returnBuffer를 HEAD request와 함께 사용하십시오. FourA는 HEAD를 올바르게 처리하므로(내부적으로 일반적인 libcurl 에러 방지), body를 가져오지 않고도 header를 검사할 수 있습니다. Content-Type을 확인하고 다운로드할 가치가 있는지 결정한 다음, returnBuffer: true로 전체 request를 수행하십시오.

그리고 JavaScript가 많은 대상을 위해 브라우저 작업을 사용하는 경우, 이러한 옵션은 직접 HTTP 엔진에 적용된다는 점에 유의하십시오. 브라우저 request는 Chrome의 내장 내비게이션을 통해 redirect를 처리하며, 이는 기본적으로 제한 없이 redirect를 추적합니다.

향후 계획

저희는 API를 통해 커스텀 DNS 확인, 단계별 타임아웃 조정, 인증서 처리 옵션 등 더 많은 request 수준의 제어 기능을 제공하기 위해 노력하고 있습니다. 목표는 인프라 오버헤드 없이 깔끔한 REST 인터페이스를 통해 완전한 curl-impersonate 기능을 제공하는 것입니다.

필요한 특정 옵션이 있다면 언제든 의견을 보내주십시오. 대시보드에서 이미 이러한 새로운 옵션을 적용한 request의 성능을 보여주고 있으므로, 차이를 직접 측정해 볼 수 있습니다.