확장자는 이름이고 Content-Type은 전달한 형식의 선언입니다
Content-Type은 요청이나 응답 본문의 원래 미디어 형식을 알립니다. 주소가 .json으로 끝나도 서버가 로그인 HTML을 반환할 수 있고 .pdf라는 이름만 붙여도 실제 내용이 PDF로 바뀌지는 않습니다. 따라서 파일 형식 확인에는 상태·Content-Type·실제 본문을 함께 봐야 합니다. 근거: MDN Content-Type, 2026-11-04.
근거: MDN Content-Type · 2026-11-04 확인
JSON을 기대했는데 HTML이 온 예제를 나눠 봅니다
가상의 /report.json 요청에 로그인 화면이 반환되었다고 합시다. 이를 무조건 JSON으로 읽으면 문법 오류가 나지만 원인은 JSON 생성 코드가 아니라 인증·이동 경로일 수 있습니다. Network에서 최종 주소, 상태, Content-Type과 본문 첫 부분을 봅니다. 본문이 로그인 안내라면 먼저 인증 경로를 해결하고 형식 선언만 JSON으로 고쳐 오류를 숨기지 않습니다. 실제 응답을 받은 사례가 아닌 진단 예입니다.
근거: MDN Content-Type · 2026-11-04 확인
보내는 본문과 받고 싶은 형식은 별도로 적습니다
JSON 본문을 보내는 요청에서는 Content-Type: application/json과 실제 JSON 인코딩을 맞춥니다. 받고 싶은 표현은 Accept로 제안할 수 있어 두 헤더의 역할이 다릅니다. 서버가 엄격하면 지원하지 않는 형식에415를 반환할 수 있습니다. 이때 오류를 없애기 위해 헤더 문자열만 바꾸기 전에 본문이 실제로 그 형식인지, API가 어떤 형식을 허용하는지 확인합니다.
근거: MDN Content-Type · 2026-11-04 확인
확인 성공은 파싱과 업무 구조까지 포함합니다
허가된 테스트 응답의 상태와 형식을 읽고 실제로 해당 형식으로 파싱합니다. 그 뒤 필수 필드·단위·문서 종류가 요구와 맞는지 확인합니다. JSON 파싱 성공은 필드의 의미가 맞다는 증거가 아니며 PDF 형식 확인도 내용 검수와는 다릅니다. 실패 기록에는 비밀을 제거한 최종 주소·상태·형식·파싱 오류를 남기고, 실제 본문을 조사하지 못했다면 형식 확인 완료로 표시하지 않습니다.
원문으로 이어 읽기
확인일: 2026-11-04. 정의와 적용 범위, 발행일과 판본을 함께 살펴봅니다. 원문이 존재한다는 사실만으로 개별 주장의 정확성과 재사용 권리가 자동 보장되지는 않습니다.