Accept와 Content-Type은 둘 다 형식인데 왜 따로 있을까

Accept는 이해할 형식의 제안이고 Content-Type은 실제 형식의 선언입니다

요청의 Accept는 클라이언트가 이해할 수 있는 미디어 형식을 알리고 서버는 협상을 통해 선택할 수 있습니다. 선택한 응답 형식은 Content-Type에서 읽습니다. 보내는 본문의 Content-Type과 받고 싶은 형식의 Accept를 같은 값으로 묶어야 하는 것은 아닙니다. 근거: MDN Accept, 2026-11-04.

근거: MDN Accept · 2026-11-04 확인

이미지 업로드와 JSON 결과는 함께 성립할 수 있습니다

가상의 API에서 이미지를 제출하고 처리 결과를 JSON으로 받고 싶다면 업로드 본문 형식과 응답 선호 형식이 다릅니다. 서버가 요구하는 실제 업로드 방식은 해당 문서에서 확인해야 하며 파일을 보내는데 Content-Type만 JSON이라고 적어서는 안 됩니다. 반대로 Accept: application/json을 보냈다는 사실만으로 정상 JSON 응답을 반드시 받았다고 기록하지 않습니다.

근거: MDN Accept · 2026-11-04 확인

여러 선호값은 실제 지원과 비교합니다

클라이언트가 여러 형식을 제안하더라도 서버가 제공하는 표현과 일치해야 합니다. 브라우저는 이미지·스타일·문서 등 요청 맥락에 따라 Accept 값을 정할 수 있으므로 서로 다른 요청의 헤더가 다르다는 사실만으로 오류라고 보지 않습니다. 우선 해당 API가 제공하는 응답 형식 목록과 요청한 값을 비교하고 광범위한 와일드카드가 필요한지 목적에 맞춰 검토합니다.

근거: MDN Accept · 2026-11-04 확인

파싱 실패의 진단 자료는 세 종류입니다

허가된 시험에서 요청 Accept, 응답 상태와 Content-Type, 실제 본문 형식을 기록합니다. 오류 HTML이나 로그인 안내가 왔다면 무조건 JSON으로 읽지 말고 상태·최종 주소·인증 경로를 봅니다. 본문이 JSON이더라도 필요한 필드가 없는 경우는 협상과 다른 업무 데이터 문제일 수 있습니다. 전송 자료를 공유할 때는 토큰·쿠키·개인 데이터를 제거합니다.

성공은 요구한 결과를 올바른 형식으로 읽은 상태입니다

원하는 형식을 요청했고 서버가 그에 맞는 표현을 반환하며 파싱과 필요한 필드 검증이 끝났는지 봅니다. 지원되지 않는 형식이면 공식 허용 목록에서 선택하거나 다른 엔드포인트를 확인합니다. 오류를 없애려고 Accept만 아무 값으로 바꾸고 실제 데이터 검사를 생략하지 않습니다. 이 글에서는 업로드·콘텐츠 협상을 실행하지 않았습니다.

옆 문서로 이어가기