JSON 포맷

JSON—JavaScript Object Notation—은 구조화된 데이터 교환을 위한 유비쿼터스 텍스트 기반 형식입니다. IETF에 의해RFC 8259로, Ecma International에 의해ECMA-404로 표준화되었으며, 이들은 함께 현대 API, 로그, 구성 및 데이터베이스를 구동하는 간결하고 언어에 구애받지 않는 구문을 정의합니다.

구문 및 인코딩: 시스템 간의 통신을 유지하는 정밀한 비트

JSON 값은 객체, 배열, 문자열,숫자 또는 리터럴 true, false,null 중 하나입니다. 객체는 문자열을 값에 매핑하고 배열은 순서가 있는 값을 보유합니다. 구조 문자 주위에 중요하지 않은 공백이 허용됩니다(RFC 8259,ECMA-404). JSON은 JavaScript에서 유래했지만 언어 독립적이며 거의 모든 곳에서 지원됩니다(MDN: JSON). 유선상에서 사실상의 권장 인코딩은 UTF-8입니다(RFC 8259 §8.1). 추가적인 상호 운용성 안전을 위해I-JSON 프로필(RFC 7493)은 인코딩 및 숫자 범위에 대한 규칙을 강화합니다.

JavaScript에서 전역 JSON 객체는 두 가지 주력 기능을 제공합니다.JSON.parse(선택적 reviver 포함) 및JSON.stringify(예쁜 인쇄를 위한 replacer/spacing 포함)이며, MDN에 문서화되어 있습니다(parse,stringify).

숫자: 보기에는 간단하지만 놀랍도록 날카로움

JSON의 숫자 문법은 10진수이지만 사양에서는 정밀도나 정수/부동 소수점 구분을 지정하지 않습니다. 구현에서 이를 표현하는 방법을 선택합니다(RFC 8259 §6). JavaScript 및 Node.js에서 Number는 IEEE-754 배정밀도이므로 [−(2^53−1), 2^53−1] 범위의 정수만 정확하게 안전합니다.Number.MAX_SAFE_INTEGER및BigInt 유형을 참조하십시오. 이것이 공개 API가 종종 ID를 문자열로 제공하고 "안전한 정수"를 명시적으로 확인하는 이유입니다.

바닐라 JSON을 넘어: 포인터, 패치 및 병합 패치

사용이 성숙해짐에 따라 JSON을 제자리에서 주소 지정하고 수정하기 위한 표준이 등장했습니다.JSON 포인터(RFC 6901)는 값을 찾는 작은 슬래시로 구분된 구문(예: /a/b/0)이며 ~ 및 /에 대한 이스케이프 규칙이 있습니다.JSON 패치(RFC 6902)는 부분 업데이트를 순서가 있는 작업(add, remove, replace, move, copy, test)으로 모델링하고 application/json-patch+json으로 전송됩니다. 더 간단한 차이점의 경우JSON 병합 패치(RFC 7386)는 문서 모양의 병합을 사용합니다. 있는 필드는 추가/교체되고 필드를 null로 설정하면 삭제됩니다. 많은 프레임워크가 기본적으로 하나 또는 두 가지 형식을 모두 지원합니다.

스키마 및 유형: 유효성 검사 및 생성

JSON 자체는 스키마가 없지만 생태계는 유효성 검사, 문서화 및 코드 생성을 위해 스키마에 의존합니다.JSON 스키마 2020-12계열은 type, properties, items와 같은 제약 조건과 구성 키워드를 지정하며OpenAPI 3.1과 일치합니다. 코드 생성 중심 워크플로의 경우JSON 유형 정의(RFC 8927)는 주류 유형 시스템에 예측 가능하게 매핑되는 의도적으로 덜 표현적인 언어를 제공합니다.

스트리밍 및 빅 데이터: JSON 라인 및 시퀀스

클래식 JSON은 페이로드당 하나의 완전한 텍스트를 예상하므로 스트리밍 로그 및 장기 실행 응답이 복잡해집니다. 두 가지 패턴이 도움이 됩니다.

• JSON 텍스트 시퀀스(RFC 7464): UTF-8 JSON 텍스트 스트림으로, 각각 레코드 구분 기호(U+001E)가 접두사로 붙고 LF로 끝납니다. application/json-seq로 등록되었습니다.
• NDJSON / JSON Lines: 각 줄은 독립 실행형 JSON 값으로, 추적, gzip 압축 및 맵리듀스가 용이합니다(ndjson.org,jsonlines.org). Elasticsearch의Bulk API와 같은 대량 API에서 널리 사용됩니다.

바이너리 사촌: 텍스트가 충분히 간결하지 않을 때

대역폭이나 속도가 중요할 때 "바이너리 JSON" 형식은 JSON의 데이터 모델을 유지하면서 사람이 읽을 수 있는 가독성을 효율성과 맞바꿉니다.

• BSON(MongoDB의 기본 형식)은 바이너리, 날짜/시간 및 형식화된 정수와 같은 유형을 추가합니다(bsonspec.org).
• MessagePack은 간결하고 스키마가 없으며 여러 언어에서 널리 구현됩니다(msgpack.org).
• CBOR은 확장 가능하고 간결한 형식(JSON 트랜스코딩 지침 포함)을 표준화하며 IoT/제한된 컨텍스트에서 일반적입니다(RFC 8949,cbor.io).
• Smile(Jackson 에코시스템에서)은 반복되는 이름/값에 대한 선택적 역참조를 사용하여 JSON을 인코딩합니다(jackson-dataformat-smile).

보안 참고 사항: 오래된 트릭과 최신 수정

JSON은 텍스트일 뿐이므로 대부분의 위험은 전송 및 처리 방식에서 비롯됩니다.

• JSONP(콜백과 함께 <script>를 통해 데이터 요청)는 교차 출처 요청에 대한 CORS 이전 해결 방법이었지만 임의의 스크립트를 실행하므로 위험합니다. 실제 application/json 응답과 함께CORS를 선호하십시오(OWASP: JSONP Abuse).
• JSON 하이재킹: 민감한 배열을 반환하는 순진한 GET 엔드포인트는 이전 브라우저에서 교차 출처 스크립트 태그를 통해 도용될 수 있습니다. 완화 조치에는 CSRF 보호 기능이 있는 POST 또는 비 JSON 센티널 접두사 추가가 포함됩니다(OWASP: JSON Hijacking).
• JSON 삽입: JSON을 코드가 아닌 데이터로 취급하십시오. 부지런히 이스케이프하고 입력을 확인하십시오(OWASP: JSON Injection).

미디어 유형 및 유산

JSON은RFC 4627(2006)에서 데뷔했습니다. 등록된 미디어 유형은application/json이며, 현재 사양은RFC 8259를 가리킵니다. 공용 인터넷에서는 UTF-8이 기본값이므로 JSON 응답의 "charset" 매개변수는 일반적으로 불필요합니다.

프로덕션에서 강력한 JSON을 위한 실용적인 팁

• 어디서나 UTF-8을 기본값으로 사용하십시오. 입력 및 출력에서 UTF-8을 가정하십시오(RFC 8259 §8.1).
• 큰 정수를 명시적으로 처리하십시오. ID가 2^53-1을 초과할 수 있는 경우 문자열로 제공하고 문서화하십시오(MDN: MAX_SAFE_INTEGER).
• JSON 스키마 2020-12(또는 코드 생성 중심 스택의 경우JTD)로 페이로드를 확인하십시오. API 문서 옆에 스키마를 게시하십시오(OpenAPI 3.1).
• 현명하게 패치하십시오. 작업 수준 차이에는JSON 패치를, 간단한 문서 모양 업데이트에는병합 패치를 사용하십시오.
• 대규모로 스트리밍하십시오. 로그 및 장기 실행 응답에는JSON 텍스트 시퀀스또는NDJSON을 선택하고 미디어 유형을 명시적으로 만드십시오.
• 텍스트가 병목 현상일 때 바이너리(BSON,MessagePack,CBOR,Smile)를 사용하되 양쪽 끝이 유형에 동의하는지 확인하십시오.

"더 친숙한 JSON"에 대한 간단한 설명

개발자는 종종 구성 파일에 주석, 후행 쉼표 또는 작은따옴표로 묶인 문자열을 원합니다. 이는 표준 JSON의 범위를 벗어나지만JSON5는 사람이 편집하는 파일에 대해 잘 문서화된 상위 집합을 제공합니다. 양쪽 끝을 제어하지 않는 한 공개 API를 통해 JSON5를 보내지 마십시오.

JSON의 성공은 작은 표면적, 광범위한 언어 지원 및 분산 시스템의 지저분한 현실을 다루는 인접 표준(포인터, 패치, 스키마, 시퀀스)의 고리에서 비롯됩니다. 기본 사항(구문, 인코딩, 숫자)을 이해하고 올바른 인접 표준에 의존하면 스택과 서비스 전반에 걸쳐 계속해서 이점을 얻을 수 있습니다(RFC 8259,ECMA-404,RFC 6901,RFC 6902,RFC 7386,JSON Schema,JTD,RFC 7464,NDJSON).