Content-Type은 본문 형식을 약속하는 헤더예요

Content-Type은 본문 형식을 약속하는 헤더예요 thumbnail

Content-Type은 서버와 클라이언트가 주고받는 데이터의 형식을 약속하는 헤더예요. JSON을 보내는데 서버가 폼 데이터라고 생각하면 파싱이 어긋나요. 반대로 HTML을 보내는데 브라우저가 JSON으로 해석하려고 하면 화면이 깨져요.

요청과 응답에서 역할이 달라요

Content-Type은 요청 본문과 응답 본문의 형식을 설명해요. 요청에서는 "내가 보내는 데이터가 무엇인지"를 알려주고, 응답에서는 "내가 돌려주는 데이터가 무엇인지"를 알려줘요.

예를 들어 JSON API에 요청을 보낼 때는 이런 식으로 써요.

POST /api/users HTTP/1.1
Content-Type: application/json

{"name":"yeonjoong"}

서버는 이 헤더를 보고 본문을 JSON으로 파싱할 수 있어요. 파일 업로드라면 multipart/form-data, HTML 폼이라면 application/x-www-form-urlencoded가 더 어울려요.

MIME type이 기준이에요

Content-Type은 MIME type을 기반으로 해요. 보통 type/subtype 형태로 쓰고, 필요하면 charset이나 boundary 같은 매개변수를 덧붙여요.

application/json: JSON API
text/html: HTML 응답
multipart/form-data: 파일 업로드
application/x-www-form-urlencoded: 전통적인 HTML form 제출

본문 형식과 헤더가 다르면 서버는 잘못된 방식으로 데이터를 읽을 수 있어요. 이때는 415 Unsupported Media Type 같은 오류가 나올 수 있어요.

charset도 자주 놓쳐요. 텍스트 기반 데이터는 인코딩 정보가 있어야 글자가 깨지지 않아요. 다만 JSON은 보통 UTF-8을 기대하기 때문에, 대부분의 경우 application/json만으로도 충분해요.

Content-Type과 Accept는 반대 방향이에요

많이 헷갈리는 값이 Accept예요. Content-Type은 보내는 데이터의 형식이고, Accept는 받고 싶은 응답의 형식이에요.

헤더	의미
`Content-Type`	내가 보내는 본문의 형식
`Accept`	내가 받고 싶은 응답의 형식

클라이언트가 Accept: application/json을 보내면 서버는 가능한 한 JSON으로 응답하려고 해요. 하지만 서버가 Content-Type: application/json 없이 JSON을 보내면, 브라우저나 클라이언트는 그 데이터를 올바르게 다루지 못할 수 있어요.

방향이 반대라는 사실만 기억해도 헷갈림이 크게 줄어요. 하나는 "내가 보내는 것", 다른 하나는 "내가 받고 싶은 것"이에요.

자주 하는 실수

가장 흔한 실수는 본문은 바꿨는데 헤더를 그대로 두는 일이에요. JSON으로 바꿨으면 Content-Type도 같이 바뀌어야 해요. 또 multipart/form-data를 쓸 때는 boundary를 클라이언트가 자동으로 붙여 주는지 확인해야 해요. 직접 문자열만 넣어 두면 업로드가 실패할 수 있어요.

응답에서도 비슷한 실수가 생겨요. HTML을 내려주면서 application/json을 붙이거나, API 응답인데 text/plain으로 두면 클라이언트가 기대한 방식으로 처리하지 못해요.