하이라이트
이제 Activity에서 임의의 request를 클릭하면 전체 payload를 볼 수 있습니다. 클릭 한 번으로 Playground에서 해당 항목이 미리 채워진 상태로 다시 열리며, 바로 재실행할 수 있습니다. 또한 사용자의 request를 가짜 response로 다시 에코하는 일종의 "proxy"를 감지하여 데이터가 오염되는 것을 방지했습니다.
새로운 기능
Activity → Playground: 모든 request 재실행
모든 API 호출은 X-Foura-Request-Id header와 함께 반환됩니다. 동일한 ID가 Activity의 request 옆에 표시됩니다. 임의의 행을 클릭하면 실행 시점, 생성한 키, request body, response, 상태 코드, 소요 시간 등 전체 정보를 확인할 수 있습니다. "Open in Playground"를 클릭하면 request가 폼에 미리 채워진 상태로 로드됩니다.
이전에는 재실행을 위해 기억에 의존하여 request를 다시 구성해야 했습니다. 이제 Activity가 이력을 보관하며, Playground가 재실행 버튼 역할을 합니다.
참고할 몇 가지 동작 방식이 있습니다. API 키당 최근 200개의 payload를 24시간 동안 보관합니다. 그 이후에는 새로운 항목이 들어옴에 따라 오래된 항목부터 삭제됩니다. payload 만료 시, 이전처럼 혼란스러운 null 또는 "(empty body)"를 표시하는 대신 다이얼로그를 통해 알려줍니다.
request ID를 연동할 수도 있습니다. 클라이언트 측에서 자체 request ID와 함께 X-Foura-Request-Id response header를 기록해 두면, 나중에 일치하는 Activity 행을 복사-붙여넣기 한 번으로 쉽게 찾을 수 있습니다.
캡처 작업은 메인 실행 경로(hot path) 외부에서 처리됩니다. 따라서 API request가 이 작업으로 인해 대기하지 않습니다. 또한 캡처 저장소에 연결할 수 없더라도 호출은 정상적으로 진행되며, 나중에 다이얼로그에 "no body captured"라고 표시될 뿐입니다.
response body 기준 검증
Playground의 Validate 섹션에 body 콘텐츠 규칙이 추가되었습니다. 여러 대안을 |로 구분하여 "response에 X가 포함된 경우에만 성공" 또는 "Y가 포함된 경우 실패"와 같이 지정할 수 있습니다. Single 및 Proxy에서 작동합니다. 실제 발생한 상황과 상태 코드가 일치하지 않을 때 유용합니다.
body가 없는 payload의 명확한 상태 표시
실패한 request에는 표시할 response body가 없습니다. 이전 다이얼로그에서는 이를 null 또는 "(empty body)"로 렌더링하여 실제 빈 response로 오해하기 쉬웠습니다. 이제 다이얼로그는 request 실패(실제 에러 메시지 포함), payload 캡처되지 않음, 또는 서버가 실제로 0바이트를 반환함의 세 가지 케이스를 구분하여 보여줍니다.
사소한 변경이지만, "잠깐, 이게 실제 response인가 아니면 UI 버그인가?" 하는 혼란을 줄여줍니다.
Playground의 Reset 버튼
클릭 한 번으로 활성화된 endpoint의 폼을 기본값으로 되돌립니다. 대부분의 사용 사례에 맞추어 기본값은 unblocker 및 tryJsonData가 켜진 상태로 유지됩니다.
내부 동작 원리
Honeypot proxy 감지
실제 환경의 일부 "proxies"는 실제로 전달(forward)하지 않습니다. 이들은 운영자가 내부 정보를 탈취할 수 있도록 사용자의 request를 일반 텍스트 형태의 서버 변수 덤프(HTTP 메서드, headers, 대상 호스트)로 다시 에코합니다. 단일 세션 내에서 동일한 proxy가 한 번은 request를 전달하고, 다음번에는 에코하며, 그 다음에는 502 에러를 반환하는 현상을 확인했습니다.
이제 body validator가 response가 에지를 벗어나기 전에 이러한 덤프의 시그니처를 감지합니다. Single은 명확한 실패를 반환합니다. Proxy Finder는 다른 proxy로 재시도합니다. Browser도 공유 HTTP 레이어로부터 동일한 guard를 상속받습니다. 따라서 Activity에 불필요한 가비지 행이 줄어들고, 스크레이퍼가 데이터처럼 보이지만 실제로는 조사(probe) 시도인 데이터를 수집하지 않게 됩니다.
아직 평판 점수(reputation)를 변경하지는 않습니다. 해당 proxy는 당분간 풀에 유지됩니다. 다만 해당 proxy의 거짓된 결과를 사용자에게 반환하지 않도록 차단할 뿐입니다.
따라서 이전에는 불완전한 "success"처럼 보였던 request가 Activity에서 명확한 실패(hard failure)로 표시된다면, 이는 guard가 이를 감지해 낸 것입니다. 오염된 레코드보다는 명확한 실패가 더 낫습니다.