크롬에서 API 요청을 수정해 재전송하는 법

요청을 골라 Console에서 고친 뒤 실행한다

폼을 여러 번 입력하지 않고 API 입력값만 바꾸려면, 크롬 개발자도구의 Network → 요청 우클릭 → Edit and resend as fetch를 사용한다. 요청이 fetch() 코드로 Console에 들어가며, 편집한 뒤 Enter를 눌러 다시 보낸다. 메뉴를 고르는 것과 요청을 실행하는 것은 별도 단계다.

Chrome 153·154를 다룬 10월 DevTools 업데이트는 이 메뉴가 Console로 포커스를 옮기고 요청 코드를 입력창에 넣는 동작을 설명한다. 매번 코드를 복사해 붙여 넣는 수고를 줄인 변화다.

1. DevTools의 Network를 열고, 조사할 요청을 만드는 화면 동작을 한 번 수행한다.
2. 해당 API 요청을 찾아 우클릭한 뒤 Edit and resend as fetch를 선택한다.
3. Console에 들어온 코드에서 바꿀 URL·헤더·본문을 수정하고 Enter를 누른다.
4. Network에 새로 기록된 요청을 열어 Headers의 상태와 Response의 내용을 원래 요청과 비교한다.

공식 Network 문서의 적용 대상은 fetch로 보낼 수 있는 요청이다. 이미 끝난 요청의 서버 처리를 바꾸는 동작이 아니라 새 요청을 만드는 과정이다.

입력 조건을 하나씩 바꾸면 응답 차이를 읽기 쉽다

예를 들어 개발 중인 검색 API가 결과를 20개씩 돌려주는데 50개를 요청했을 때를 보고 싶다고 하자. 캡처한 코드의 다른 조건은 유지하고 페이지 크기만 바꾸면 된다. 다음 표는 Fetch API의 입력 구조를 디버깅 상황에 적용한 예다.

한 번에 여러 조건을 고치면 어떤 변경이 결과를 바꿨는지 다시 따져야 한다. 입력 한 항목을 바꾸고 새 응답을 보는 방식은 이 비교를 단순하게 만든다. 주문 생성처럼 상태를 바꾸는 요청은 재실행하면 같은 작업을 다시 요청하므로, 개발용 데이터와 대상 API를 먼저 맞춰야 한다.

Copy as fetch는 복사, Local overrides는 응답 대체다

Copy → Copy as fetch는 요청을 fetch 코드로 클립보드에 복사한다. 직접 붙여 넣고 편집할 때 쓰는 경로다. Edit and resend as fetch는 이 편집을 Console에서 바로 시작하게 한다.

반면 Local overrides는 브라우저가 받는 응답 내용이나 응답 헤더를 로컬 값으로 대체한다. 아직 서버에 없는 응답 모양으로 화면을 시험할 때 유용하다. 서버가 수정한 입력을 제대로 처리하는지 보려는 실험과는 목적이 다르다.

서버 응답을 비교하는 동안에는 Sources → Overrides의 Enable Local Overrides 상태도 봐야 한다. 대체 응답이 켜져 있으면 화면에 보이는 값이 실제 서버 응답이라고 생각하기 쉽다.

실패하면 실행 위치와 인증 조건을 확인한다

현재 Chrome 문서는 이 기능이 원래 요청의 매개변수와 실행 컨텍스트를 보존한다고 설명한다. 다만 코드를 수동으로 옮겼다면 실행 위치를 다시 봐야 한다. Console의 JavaScript Context에서 top은 메인 문서다. iframe 안의 코드를 실행할 때는 해당 프레임의 컨텍스트를 선택한다.

fetch의 인증 정보 전송 기본값은 same-origin이다. 다른 출처로 URL을 바꿨다면 기존 쿠키가 그대로 전달될 것으로 가정할 수 없다. CORS 조건도 계속 적용된다. no-cors로 바꾸면 자바스크립트에서 응답 본문을 읽을 수 없는 opaque 응답이 될 수 있어, API 응답 확인의 해결책이 되지 않는다.

수정한 요청, 새로 받은 응답, 실행한 페이지를 함께 비교해야 한다. Console에서 코드를 실행했다는 사실만으로 원래 요청과 같은 조건의 서버 테스트가 끝나는 것은 아니다.