개요

application/json은 JavaScript Object Notation으로 직렬화한 데이터를 나타내는 미디어 타입으로, 오늘날 REST API와 웹 프런트엔드가 데이터를 주고받는 사실상의 표준입니다. 키-값 객체와 배열을 텍스트로 표현하며 사람이 읽기 쉽고 거의 모든 언어에 파서가 내장되어 있습니다.

자세히

RFC 8259가 정의하는 JSON 텍스트는 반드시 UTF-8, UTF-16, UTF-32 중 하나로 인코딩되며, 네트워크로 교환할 때는 UTF-8이 유일한 기본값입니다. 이 때문에 application/json에는 charset 파라미터가 정의되어 있지 않습니다. `Content-Type: application/json; charset=utf-8`처럼 붙여도 무시되며, 인코딩은 항상 바이트 순서 표시나 첫 문자를 보고 판별합니다. 서버가 Latin-1 같은 다른 인코딩으로 한글·이모지를 내보내면 파싱이 깨집니다.

본문은 객체·배열·문자열·숫자·true·false·null로 구성되며, 주석과 후행 쉼표(trailing comma)를 허용하지 않습니다. 숫자는 IEEE 754 배정밀도로 다뤄지므로 2^53을 넘는 정수(예: 트위터 스노플레이크 ID, int64)는 정밀도가 손실됩니다. 큰 정수는 문자열로 직렬화하는 것이 안전합니다. API에서는 Accept: application/json으로 협상하고, 응답 Content-Type에도 동일 타입을 붙입니다.

문법

e.g. Content-Type: application/json; charset=utf-8

파일 확장자

실무 참고

• charset 파라미터는 규격상 정의되지 않았지만, 일부 구형 클라이언트를 달래려고 관습적으로 붙이기도 합니다. 붙여도 무해하나 인코딩을 바꾸지는 못합니다 — 항상 UTF-8로 내보내세요.
• 브라우저에서 JSON 응답을 <script>로 직접 실행할 수 없게 하려면, 민감한 JSON 배열 앞에 `)]}',\n` 같은 방어 프리픽스를 붙이는 관행(구글식)이 있습니다. JSON 하이재킹 예방책입니다.
• top-level이 배열인 JSON은 과거 일부 브라우저에서 CSRF 위험이 있었고, `Content-Type`을 무시하고 스니핑당하지 않도록 `X-Content-Type-Options: nosniff`를 함께 보내는 것이 좋습니다.

관련 타입

관련 헤더