JSON은 두 개의 자바스크립트 리터럴을 웹의 데이터 형식으로 바꾸었다

XML은 태그, 네임스페이스, 스키마라는 문법으로 기계 간 데이터에 표현력을 부여했지만, 단순한 레코드 하나를 보내려 해도 문서를 작성해야 할 만큼 무거웠다. JSON은 반대의 길을 택했다. JSON 홈페이지의 표현대로, JSON은 이름/값 쌍의 집합과 값의 순서 있는 목록이라는 두 구조 위에 세워져 있으며, C, C++, C#, Java, JavaScript, Perl, Python 프로그래머에게 이미 익숙한 관례를 따라 작성된다. 바로 그렇기 때문에 그 페이지들은 JSON을 이상적인 데이터 교환 언어라고 부른다.

이 형식의 계보와 자바스크립트로부터의 탈출은 모두 표준화 과정에 드러난다. RFC 8259, 'The JavaScript Object Notation (JSON) Data Interchange Format'은 ECMAScript에 정의된 자바스크립트 리터럴에서 파생된, 가볍고 텍스트 기반이며 언어에 독립적인 데이터 교환 형식을 설명한다. 이는 모든 웹 브라우저가 알아볼 수 있지만 어느 브라우저에도 속하지 않는다. IETF의 JSON 워킹 그룹은 RFC 7159를 거쳐 RFC 8259까지 이를 이끌었고, 2017년 12월 JSON을 인터넷 표준으로 만들었다.

그 결과는 대체였다. 한때 API가 XML 스키마를 협상하던 곳에서 이제는 어떤 프로그래머든 한눈에 읽을 수 있는 객체와 배열을 반환한다. 즉, 채택자가 모집되기 위해 표준화 과정이 필요했던 것이 아니라, 채택이 이루어진 뒤에야 표준화 과정에 도달한 형식이다.

두 구조만으로 모든 API에 충분하다

객체와 배열이라는 두 구조가 결합되어 프로그램이 시스템 간에 주고받는 거의 모든 데이터 형태를 이룰 수 있었기에, 이 형식에는 확장 메커니즘이 필요하지 않았다.

자바스크립트 리터럴에서 문법을 끌어온 덕분에 이 형식은 가장 빠르게 성장하는 개발자 집단에게 즉시 읽혔고, 언어 독립성은 다른 모든 커뮤니티를 포용했다.

스키마나 태그 어휘가 필요하지 않았기에, API는 문서 형식 정의를 조율하지 않고도 페이로드를 바꿀 수 있었다.

채택 이후 IETF를 통한 표준화는, 선행 형식을 매력 없게 만든 무게를 부과하지 않으면서 상호운용성을 확정했다.

형식은 덜어냄으로써 이긴다. 구성 요소가 적을수록 이견이 적어지며, 어떤 프로그래머든 문서 없이 읽을 수 있는 데이터 형식은 더 풍부했던 선행 형식들을 정체시킨 저항을 없앤다.

RFC 8259는 2017년 12월 JSON을 공식 인터넷 표준으로 만들었으며, 그 시점에 JSON은 이미 웹 API, 구성, 로그 데이터의 기본 교환 형식이 되어 있었다. 이는 워킹 그룹이 세계의 기존 관행을 비준함으로써 형식이 표준화된 드문 사례다.