Bagaimana Douglas Crockford memopulerkan JSON dan mengapa JSON menjadi bahasa default untuk aplikasi web dan API—plus tips praktis agar penggunaan JSON tetap baik hari ini.

JSON (JavaScript Object Notation) adalah cara ringan untuk merepresentasikan data sebagai teks biasa menggunakan pasangan kunci–nilai dan daftar.
Jika Anda membangun aplikasi web—bahkan jika Anda tidak terlalu memikirkan “format data”—JSON kemungkinan besar sudah menjadi perekat yang menjaga produk Anda berjalan. Itulah cara frontend meminta data, cara backend merespons, bagaimana aplikasi seluler menyinkronkan status, dan bagaimana layanan pihak ketiga mengirimkan event. Ketika JSON jelas dan konsisten, tim merilis lebih cepat; ketika berantakan, setiap fitur memakan waktu lebih lama karena semua orang berdebat tentang apa arti data tersebut.
Berikut objek JSON kecil yang bisa Anda baca sekilas:
{
"userId": 42,
"name": "Sam",
"isPro": true,
"tags": ["beta", "newsletter"]
}
Bahkan tanpa konteks teknis, Anda biasanya bisa menebak apa yang terjadi: seorang pengguna memiliki ID, nama, flag status, dan daftar tag.
Anda akan mempelajari:
Tujuannya sederhana: membantu Anda memahami bukan hanya apa itu JSON, tetapi juga mengapa hampir setiap aplikasi “berbicara” dengannya—dan bagaimana menghindari kesalahan umum yang terus diulang tim.
Douglas Crockford tidak “menemukan” setiap ide di balik JSON, tetapi dia melakukan sesuatu yang sama pentingnya: membuat pola yang sederhana dan bisa dipakai terlihat, menamainya, dan mendorongnya ke arus utama.
Di masa awal aplikasi web, tim berjuang dengan pilihan canggung untuk memindahkan data antara browser dan server. XML umum digunakan tetapi verbose. Format kustom berbasis pembatas ringkas tapi rapuh. JavaScript secara teknis bisa mengevaluasi data sebagai kode, tetapi itu mengaburkan batas antara “data” dan “script yang dapat dieksekusi,” yang menjadi sumber bug dan masalah keamanan.
Crockford melihat jalan yang lebih bersih: gunakan subset kecil dari sintaks literal JavaScript yang bisa merepresentasikan data biasa secara andal—objek, array, string, angka, boolean, dan null—tanpa fitur tambahan.
Salah satu kontribusi terbesar Crockford bersifat sosial, bukan teknis: dia menamainya JSON (JavaScript Object Notation) dan menerbitkan dokumentasi jelas di json.org. Itu memberi tim kosakata bersama (“kita akan mengirim JSON”) dan referensi yang cukup singkat untuk dibaca serta cukup ketat untuk diimplementasikan.
Dia juga mempromosikan JSON sebagai format data yang independen dari JavaScript sebagai bahasa pemrograman: banyak bahasa dapat mem-parse dan menghasilkan JSON, dan JSON terpetakan secara alami ke struktur data umum.
Adopsi mempercepat ketika tim merasa aman mempertaruhkan format untuk jangka panjang. JSON perlahan-lahan memperoleh status “taruhan aman” itu melalui tonggak yang dikenal luas:
Advokasi Crockford, dikombinasikan dengan standar ini dan ekosistem parser yang berkembang, membantu JSON bergerak dari konvensi praktis menjadi cara default aplikasi berkomunikasi—terutama lewat HTTP APIs (dibahas lebih lanjut di /blog/json-and-apis).
Sebelum JSON menjadi cara default untuk memindahkan data, web bergantung pada campuran format yang terlalu berat, terlalu tidak konsisten, atau terlalu khas untuk diskalakan antar tim.
XML adalah pilihan “standar” besar. Ia bekerja lintas bahasa, punya tooling, dan bisa merepresentasikan struktur bersarang. Namun ia membawa banyak ritual.
Saat yang sama, banyak aplikasi mengirim data sebagai query string kustom (terutama di permintaan AJAX awal): pasangan kunci/nilai yang dimasukkan ke URL atau body POST. Lainnya menciptakan format teks ad‑hoc—CSV di satu tempat, blob terpisah pipe di tempat lain—sering kali dengan aturan escaping buatan tangan yang hanya satu pengembang mengerti.
Masalah umum bukan teori belaka:
Kebanyakan aplikasi tidak membutuhkan format yang bisa mengekspresikan setiap kemungkinan struktur dokumen. Mereka butuh cara yang dapat diprediksi untuk mengirim objek, array, string, angka, dan boolean—dengan cepat, konsisten, dan minim ruang interpretasi. Format yang lebih sederhana mengurangi jumlah keputusan (dan kesalahan) yang harus dibuat tim per endpoint.
<user>
<id>42</id>
<name>Ada</name>
<isActive>true</isActive>
</user>
{
"id": 42,
"name": "Ada",
"isActive": true
}
Keduanya mengekspresikan ide yang sama, tetapi JSON lebih mudah dipindai, lebih mudah dibuat, dan lebih dekat dengan bagaimana kebanyakan aplikasi memodelkan data di memori.
Daya tahan JSON bukan kebetulan. Ia sukses karena sengaja kecil: cukup struktur untuk merepresentasikan data aplikasi nyata tanpa mengundang variasi tak berujung.
JSON memberi Anda toolkit minimal yang terpetakan dengan jelas pada cara kebanyakan aplikasi memikirkan data:
name, email)true/falseItu saja. Tidak ada tanggal, tidak ada komentar, tidak ada tipe numerik kustom, tidak ada referensi. Sederhana ini membuat JSON mudah diimplementasikan di banyak bahasa dan platform.
JSON cukup mudah dibaca untuk orang memindai log dan respons API, sementara tetap mudah untuk mesin parse dengan cepat. Ia menghindari ritual berlebih, tetapi mempertahankan delimiter yang jelas ({}, [], :) sehingga parser bisa cepat dan andal.
Tradeoff‑nya: karena JSON sangat minimal, tim harus sepakat pada konvensi untuk hal seperti timestamp, uang, dan identifier (misalnya string ISO‑8601 untuk tanggal).
Aturan ketat JSON (string ber-quote ganda, tidak ada trailing comma, set tipe tetap kecil) mengurangi ambiguitas. Sedikit ambiguitas berarti lebih sedikit kegagalan “berfungsi di mesin saya” ketika sistem berbeda saling bertukar data.
JSON mirip sintaks objek JavaScript, tetapi JSON bukan JavaScript. Ini adalah format data agnostik-bahasa dengan aturan sendiri, dapat digunakan dari Python, Java, Go, Ruby, dan di mana pun yang membutuhkan serialisasi dan interoperabilitas konsisten.
JSON tidak menang karena paling kaya fitur. Ia menang karena cocok dengan cara aplikasi web sudah dibangun: browser berat JavaScript yang berbicara ke server lewat permintaan HTTP sederhana.
Begitu browser menstandarkan JavaScript, sisi klien punya cara bawaan untuk merepresentasikan data terstruktur: objek, array, string, angka, boolean, dan null. JSON memirror primitif tersebut secara dekat, sehingga memindahkan data antara “apa yang dipahami browser” dan “apa yang dikirim server” terasa alami.
Aplikasi gaya Ajax awal mempercepat ini. Alih‑alih mereturn halaman HTML penuh, server bisa mengirim payload kecil untuk dirender UI. Respons seperti ini langsung berguna:
{
"user": {"id": 42, "name": "Sam"},
"unreadCount": 3
}
Meskipun sintaks JSON tampak seperti JavaScript, ia netral‑bahasa. Begitu server dan client di bahasa lain perlu berinteroperasi dengan frontend web, library JSON bermunculan—dan cepat menjadi “peralatan standar.” Mem-parse string JSON ke struktur data native biasanya hanya satu panggilan fungsi, dan menghasilkan JSON sama mudahnya.
Begitu framework, client API, debugger, proxy, dan alat dokumentasi mengasumsikan JSON, memilih format lain menimbulkan friksi. Pengembang bisa menginspeksi payload di devtools browser, copy/paste contoh ke test, dan mengandalkan library matang untuk encoding, decoding, dan penanganan error.
Satu respons JSON dapat melayani UI web, aplikasi seluler, layanan internal, dan integrasi pihak ketiga dengan sedikit perubahan. Interoperabilitas itu membuat JSON taruhan aman untuk tim yang membangun “satu backend, banyak frontend”—dan membantu menjadikannya kontrak default antara client dan server.
JSON tidak menang karena mewah—ia pas dengan cara web bekerja. HTTP dibangun di sekitar mengirim permintaan dan menerima respons, dan JSON adalah cara yang mudah dan dapat diprediksi untuk merepresentasikan "body" respons (atau permintaan) itu sebagai data terstruktur.
Permintaan API biasanya menyertakan method dan URL (misalnya, GET /users?limit=20). Server membalas dengan kode status (seperti 200 atau 404), header, dan body opsional.
Saat body berisi JSON, header kunci adalah:
Content-Type: application/jsonHeader itu memberi tahu client bagaimana menginterpretasikan byte yang diterima. Di jalur masuk (client → server), mengirim Content-Type: application/json memberi sinyal “saya memposting JSON,” dan server dapat mem‑parsenya secara konsisten.
JSON bekerja sangat baik untuk pola berulang yang muncul di banyak API.
Pagination sering membungkus daftar dengan metadata:
{
"data": [{"id": 1, "name": "A"}],
"pagination": {"limit": 20, "offset": 0, "total": 153}
}
Filtering dan sorting biasanya terjadi di query string URL, sementara hasil tetap berupa array JSON (atau field data). Contoh: GET /orders?status=paid&sort=-created_at.
Respons error mendapat manfaat dari bentuk standar agar client bisa menampilkan pesan dan menangani retry:
{
"error": {
"code": "invalid_request",
"message": "limit must be between 1 and 100",
"details": {"field": "limit"}
}
}
Kecocokan praktisnya sederhana: HTTP menyediakan pengantaran dan makna (verb, status code, caching), sementara JSON menyediakan struktur ringan dan mudah dibaca untuk data itu sendiri.
Ketika orang membandingkan JSON dan XML, seringkali mereka sebenarnya membandingkan “data untuk aplikasi” versus “data untuk dokumen.” Keduanya bisa merepresentasikan informasi terstruktur, tetapi JSON cenderung cocok dengan apa yang kebanyakan aplikasi pindahkan: objek sederhana, daftar, string, angka, boolean, dan null.
XML verbose berdasarkan desain. Pengulangan tag pembuka dan penutup membuat payload lebih besar dan lebih sulit dipindai di log atau inspector jaringan. JSON umumnya menyampaikan makna yang sama dengan lebih sedikit karakter dan lebih sedikit kekacauan visual, yang membantu saat debugging dan dapat mengurangi biaya bandwidth pada skala.
Ini bukan hanya estetika: payload yang lebih kecil sering berarti transfer lebih cepat dan pekerjaan lebih sedikit untuk parser dan proxy.
Sebagian besar data aplikasi secara alami terlihat seperti kamus (map kunci/nilai) dan array (daftar): pengguna dengan atribut, pesanan dengan line item, halaman dengan komponen. JSON terpeta langsung ke model mental itu, dan cocok dengan struktur data native di JavaScript dan kebanyakan bahasa modern.
XML bisa merepresentasikan struktur yang sama, tetapi biasanya membutuhkan konvensi: atribut vs elemen, elemen anak berulang untuk list, dan aturan ekstra untuk "apa yang dihitung sebagai angka" (karena semuanya adalah teks kecuali Anda menambahkan pengetikan di atasnya).
XML tetap kuat untuk use case berfokus dokumen: konten campuran (teks yang diinterleave dengan markup), alur penerbitan, dan ekosistem dengan tooling XML matang (mis. integrasi enterprise tertentu). Jika payload Anda lebih mirip dokumen daripada graph objek, XML bisa menjadi pilihan yang baik.
Jika tujuan utama Anda adalah bertukar data aplikasi antara frontend, backend, dan API, JSON biasanya pilihan yang lebih sederhana dan langsung. Jika Anda butuh markup dokumen, konten campuran, atau integrasi ke domain yang didominasi XML, XML mungkin alat yang lebih pas.
JSON terlihat seperti “objek JavaScript,” jadi tim sering menganggap bisa memperlakukannya seperti JavaScript. Di situlah bug menyelinap: JSON lebih ketat, lebih kecil, dan kurang toleran.
Beberapa masalah “berfungsi di mesin saya” muncul berulang:
{name: "Ada"} bukan JSON; { "name": "Ada" } adalah JSON.{ "a": 1, } akan gagal di banyak parser.// dan /* ... */ tidak valid. Jika Anda butuh catatan, letakkan di dokumentasi atau gunakan field terpisah (dengan hati‑hati) selama pengembangan.Kekangan ini disengaja: mereka membuat parser sederhana dan konsisten di berbagai bahasa.
JSON hanya punya satu tipe numerik: number. Tidak ada integer, desimal, atau tanggal bawaan.
"19.99") untuk menghindari perbedaan pembulatan antar sistem."2025-12-26T10:15:30Z"). Hindari format tanggal kustom yang memerlukan penebakan.JSON adalah Unicode, tetapi sistem nyata masih tersandung pada encoding dan escaping:
" dan backslash \\).Selalu parse JSON dengan parser JSON yang nyata (JSON.parse atau ekuivalen bahasa Anda). Hindari pendekatan seperti eval, meskipun terasa lebih cepat. Dan validasi input di tepi—terutama untuk API publik—agar field atau tipe tak terduga tidak menyelinap ke logika bisnis.
Payload JSON bukan sekadar “data dalam perjalanan”—ia adalah antarmuka jangka panjang antara tim, sistem, dan masa depan Anda. Perbedaan antara payload yang bertahan dan yang harus dirombak setiap kuartal biasanya disiplin membosankan: konsistensi, manajemen perubahan yang hati‑hati, dan kasus tepi yang dapat diprediksi.
Pilih aturan penamaan dan patuhi di mana‑mana:
camelCase atau snake_case) dan jangan mencampur.userId menjadi id adalah perubahan breaking walau maknanya tampak “jelas.”"count": 3 vs "count": "3") akan menyebabkan bug yang sulit dilacak.Anda bisa menghindari banyak perang versi dengan membuat perubahan bersifat aditif:
/v2/...) atau sertakan sinyal versi jelas di header—jangan ubah semantik secara diam‑diam.Klien menangani kegagalan terbaik ketika error memiliki bentuk yang konsisten:
{
"error": {
"code": "INVALID_ARGUMENT",
"message": "email must be a valid address",
"details": { "field": "email" }
}
}
Dokumentasi JSON yang bagus menyertakan contoh nyata—respons sukses dan gagal—dengan field lengkap. Sinkronkan contoh dengan perilaku produksi, dan jelaskan field mana yang opsional, nullable, atau deprecated. Ketika contoh cocok dengan respons nyata, integrasi berjalan lebih cepat dan sedikit rusak.
Jika Anda menggunakan workflow vibe‑coding untuk memutar fitur baru dengan cepat, kontrak JSON menjadi lebih penting: iterasi cepat bagus sampai klien dan layanan saling melenceng.
Di Koder.ai, tim sering menghasilkan frontend React plus backend Go + PostgreSQL lalu mengiterasi bentuk API di planning mode sebelum menguncinya. Fitur seperti snapshots dan rollback membantu ketika perubahan JSON yang “kecil” ternyata breaking, dan ekspor kode sumber memudahkan menjaga kontrak di repo serta menegakkannya dengan test.
JSON mudah dibuat—itulah kekuatannya dan juga jebakannya. Jika satu layanan mengirim "age": "27" (string) dan lainnya mengharapkan 27 (number), tidak ada yang menghentikan itu di JSON sendiri. Hasilnya sering berupa jenis bug terburuk: crash klien di produksi, atau glitch UI halus yang hanya muncul pada data tertentu.
Validasi bertujuan menangkap data buruk atau tak terduga sebelum sampai ke pihak yang mengandalkannya—frontend Anda, integrasi partner, pipeline analytics, atau aplikasi seluler.
Titik kegagalan umum meliputi field wajib yang hilang, kunci yang diubah nama, tipe yang salah, dan nilai yang “hampir benar” (seperti tanggal dalam format berbeda). Langkah validasi kecil di boundary API bisa mengubah ini dari outage menjadi pesan error yang jelas.
JSON Schema adalah cara standar untuk mendeskripsikan seperti apa JSON Anda seharusnya: properti yang wajib, tipe yang diizinkan, enum, pola, dan lainnya. Ia paling berguna ketika:
Dengan schema, Anda bisa memvalidasi request di server, memvalidasi respons di test, dan menghasilkan dokumentasi. Banyak tim menggabungkannya dengan dokumentasi API (sering via OpenAPI), sehingga kontrak eksplisit bukan lagi "pengetahuan suku". Jika Anda sudah menerbitkan docs, menautkan contoh schema dari /docs dapat menjaga konsistensi.
Tidak setiap tim butuh tooling schema lengkap sejak hari pertama. Opsi praktis meliputi:
Aturan praktis: mulai dengan contoh dan contract test, lalu tambahkan JSON Schema ketika perubahan dan integrasi mulai bertambah.
JSON terasa “ringan” saat Anda mengirim beberapa field. Pada skala—klien mobile dengan jaringan tidak stabil, API lalu lintas tinggi, halaman berat analytics—JSON bisa menjadi masalah performa atau risiko keandalan jika Anda tidak membentuk dan mengirimnya dengan hati‑hati.
Masalah skala yang paling umum bukan parsing JSON—tetapi mengirim terlalu banyak. Pagination adalah kemenangan sederhana: kembalikan potongan yang dapat diprediksi (mis. limit + cursor) sehingga klien tidak mendownload ribuan record sekaligus. Untuk endpoint yang mengembalikan objek bersarang, pertimbangkan partial responses: biarkan klien meminta hanya yang dibutuhkan (selected fields atau "include" expansions). Ini mencegah “overfetching,” di mana layar hanya butuh name dan status tetapi menerima setiap detail historis dan field konfigurasi.
Aturan praktis: desain respons berdasarkan aksi pengguna (apa yang layar butuhkan sekarang), bukan berdasarkan apa yang bisa di‑join database Anda.
Jika API Anda melayani respons JSON besar, kompresi bisa sangat mengurangi ukuran transfer. Banyak server dapat gzip atau brotli respons otomatis, dan kebanyakan client menanganinya tanpa kode tambahan.
Caching adalah tuas lain. Secara garis besar, targetkan:
Ini mengurangi unduhan berulang dan meratakan lonjakan lalu lintas.
Untuk output yang sangat besar—export, feed event, bulk sync—pertimbangkan respons streaming atau parsing incremental sehingga klien tidak harus memuat seluruh dokumen ke memori sebelum melakukan sesuatu yang berguna. Ini tidak diperlukan untuk kebanyakan aplikasi, tapi sangat berguna ketika "satu blob JSON besar" mulai timeout.
JSON mudah dilog, yang berguna sekaligus berbahaya. Perlakukan log sebagai surface produk:
Jika dilakukan dengan baik, Anda akan debugging lebih cepat sambil mengurangi risiko ekspos data tidak sengaja.
JSON bukan "selesai"—ia stabil. Yang berubah sekarang adalah ekosistem di sekitarnya: editor lebih kuat, validasi lebih baik, kontrak API lebih aman, dan lebih banyak tooling yang membantu tim menghindari perubahan breaking tak sengaja.
JSON kemungkinan besar akan tetap format wire default untuk sebagian besar aplikasi web dan mobile karena dukungan luas, mudah di‑debug, dan memetakan bersih ke struktur data umum.
Perubahan terbesar adalah menuju API bertipe: tim masih mengirim JSON, tetapi mereka mendefinisikannya lebih tepat menggunakan alat seperti JSON Schema, OpenAPI, dan code generator. Itu berarti lebih sedikit momen "tebak bentuknya", autocomplete lebih baik, dan deteksi error lebih awal—tanpa meninggalkan JSON.
Saat Anda perlu mengirim atau menyimpan banyak record secara efisien (log, event analytics, export), satu array JSON besar bisa canggung. JSON Lines (juga disebut NDJSON) menyelesaikan ini dengan meletakkan satu objek JSON per baris. Ia streaming‑friendly, dapat diproses baris per baris, dan cocok dengan tooling baris perintah.
Gunakan ini sebagai pemeriksaan cepat untuk payload yang akan hidup lebih lama dari satu sprint:
2025-12-26T10:15:00Z).null dan dokumentasikan pilihan Anda.Jika Anda ingin menggali lebih dalam, jelajahi panduan terkait di /blog—khususnya topik seperti validasi skema, versioning API, dan merancang payload untuk kompatibilitas jangka panjang.