Format JSON

JSON—JavaScript Object Notation—adalah format berbasis teks yang ada di mana-mana untuk pertukaran data terstruktur. Ini distandarisasi oleh IETF sebagai RFC 8259 dan oleh Ecma International sebagai ECMA-404, yang bersama-sama mendefinisikan sintaks ringkas dan agnostik bahasa yang mendukung API modern, log, konfigurasi, dan basis data.

Sintaks & pengkodean: bit-bit presisi yang membuat sistem tetap berkomunikasi

Nilai JSON adalah objek, array, string, angka, atau salah satu dari literal true, false, atau null; objek memetakan string ke nilai dan array menampung nilai yang diurutkan — dengan spasi putih yang tidak signifikan diizinkan di sekitar karakter struktural (RFC 8259, ECMA-404). Meskipun JSON berasal dari JavaScript, ia independen bahasa dan didukung secara virtual di mana saja (MDN: JSON). Di jaringan, pengkodean de-facto dan yang direkomendasikan adalah UTF-8 (RFC 8259 §8.1). Untuk keamanan interoperabilitas ekstra, profil I-JSON (RFC 7493) memperketat aturan seputar pengkodean dan rentang numerik.

Di JavaScript, objek global JSON mengekspos dua pekerja keras:JSON.parse (dengan reviver opsional) dan JSON.stringify (dengan replacer/spasi untuk pencetakan cantik), seperti yang didokumentasikan di MDN (parse, stringify).

Angka: tampak sederhana, ternyata tajam

Tata bahasa angka JSON adalah desimal, tetapi spesifikasinya tidak menentukan presisi atau perbedaan integer/float. Implementasi memilih cara merepresentasikannya (RFC 8259 §6). Di JavaScript dan Node.js, Number adalah presisi ganda IEEE-754, yang berarti hanya integer dalam [−(2^53−1), 2^53−1] yang benar-benar aman — lihat Number.MAX_SAFE_INTEGER dan tipe BigInt. Inilah sebabnya mengapa API publik sering mengirimkan ID sebagai string dan memvalidasi "integer aman" secara eksplisit.

Di luar JSON biasa: pointer, patch, dan merge-patch

Seiring matangnya penggunaan, standar muncul untuk mengalamatkan dan memodifikasi JSON di tempat. JSON Pointer (RFC 6901) adalah sintaks kecil yang dibatasi garis miring untuk menemukan nilai (misalnya, /a/b/0) dengan aturan escape untuk ~ dan /. JSON Patch (RFC 6902) memodelkan pembaruan parsial sebagai operasi terurut (add, remove, replace, move, copy, test) dan berjalan sebagai application/json-patch+json. Untuk perbedaan yang lebih sederhana, JSON Merge Patch (RFC 7386) menggunakan penggabungan berbentuk dokumen: bidang yang ada ditambahkan/diganti; mengatur bidang ke null akan menghapusnya. Banyak kerangka kerja mendukung satu atau kedua bentuk secara bawaan.

Skema & tipe: memvalidasi dan menghasilkan

JSON sendiri tidak memiliki skema, tetapi ekosistem bersandar pada skema untuk validasi, dokumentasi, dan pembuatan kode. Keluarga JSON Schema 2020-12 menentukan batasan seperti type, properties, items, dan kata kunci komposisi, dan selaras dengan OpenAPI 3.1. Untuk alur kerja yang berpusat pada pembuatan kode, JSON Type Definition (RFC 8927) menawarkan bahasa yang sengaja kurang ekspresif yang memetakan secara dapat diprediksi ke sistem tipe arus utama.

Streaming & big data: baris dan urutan JSON

JSON klasik mengharapkan satu teks lengkap per payload, yang mempersulit streaming log dan respons yang berumur panjang. Dua pola membantu:

• Urutan Teks JSON (RFC 7464): aliran teks JSON UTF-8, masing-masing diawali oleh Pemisah Rekaman (U+001E) dan diakhiri dengan LF; terdaftar sebagai application/json-seq.
• NDJSON / JSON Lines: setiap baris adalah nilai JSON yang berdiri sendiri — mudah diikuti, di-gzip, dan di-map-reduce (ndjson.org, jsonlines.org). Ini populer di API massal, misalnya, API MassalElasticsearch.

Sepupu biner: ketika teks tidak cukup padat

Ketika bandwidth atau kecepatan mendominasi, format "JSON biner" mempertahankan model data JSON sambil menukar keterbacaan manusia dengan efisiensi:

• BSON (format asli MongoDB) menambahkan tipe seperti biner, tanggalwaktu, dan integer bertipe (bsonspec.org).
• MessagePack padat dan tanpa skema, banyak diimplementasikan di berbagai bahasa (msgpack.org).
• CBOR menstandarisasi format yang dapat diperluas dan padat (dengan panduan transcoding JSON) dan umum dalam konteks IoT/terbatas (RFC 8949, cbor.io).
• Smile (dari ekosistem Jackson) mengkodekan JSON dengan referensi balik opsional untuk nama/nilai yang berulang (jackson-dataformat-smile).

Catatan keamanan: trik lama dan perbaikan modern

Karena JSON hanyalah teks, sebagian besar risiko berasal dari cara Anda mengangkut dan menanganinya:

• JSONP (meminta data melalui <script> dengan callback) adalah solusi pra-CORS untuk permintaan lintas-asal tetapi berbahaya — ia mengeksekusi skrip sewenang-wenang. Lebih suka CORS dengan respons application/json nyata (OWASP: Penyalahgunaan JSONP).
• Pembajakan JSON: titik akhir GET naif yang mengembalikan array sensitif dapat dicuri melalui tag skrip lintas-asal di browser lama; mitigasi termasuk POST dengan perlindungan CSRF atau mengawali dengan sentinel non-JSON (OWASP: Pembajakan JSON).
• Injeksi JSON: perlakukan JSON sebagai data, bukan kode; escape dengan rajin dan validasi input (OWASP: Injeksi JSON).

Tipe media & warisan

JSON memulai debutnya di bawah RFC 4627 (2006); tipe media yang terdaftar adalah application/json, yang spesifikasinya sekarang menunjuk ke RFC 8259. Parameter "charset" pada respons JSON umumnya tidak perlu karena UTF-8 adalah default di internet publik.

Kiat praktis untuk JSON yang kuat dalam produksi

• Gunakan UTF-8 secara default di mana saja; asumsikan UTF-8 pada input dan output (RFC 8259 §8.1).
• Jadilah eksplisit dengan integer besar: jika ID mungkin melebihi 2^53−1, kirimkan sebagai string dan dokumentasikan (MDN: MAX_SAFE_INTEGER).
• Validasi payload dengan JSON Schema 2020-12 (atau JTD untuk tumpukan yang berat pada pembuatan kode). Publikasikan skema di samping dokumentasi API Anda (OpenAPI 3.1).
• Patch dengan bijak: gunakan JSON Patch untuk perbedaan tingkat operasi dan Merge Patch untuk pembaruan sederhana berbentuk dokumen.
• Streaming dalam skala besar: pilih Urutan Teks JSON atau NDJSON untuk log dan respons yang berumur panjang; buat tipe media eksplisit.
• Gunakan biner ( BSON, MessagePack, CBOR, Smile) ketika teks menjadi hambatan — tetapi pastikan kedua ujungnya setuju pada tipe.

Sepatah kata tentang "JSON yang lebih ramah"

Pengembang sering menginginkan komentar, koma di belakang, atau string dengan tanda kutip tunggal dalam konfigurasi. Itu di luar JSON standar, tetapi JSON5 menyediakan superset yang didokumentasikan dengan baik untuk file yang diedit manusia. Hindari mengirim JSON5 melalui API publik kecuali Anda mengontrol kedua ujungnya.

Keberhasilan JSON berasal dari area permukaan yang kecil, dukungan bahasa yang luas, dan cincin standar yang berdekatan — pointer, patching, skema, urutan — yang mencakup realitas berantakan dari sistem terdistribusi. Pahami dasar-dasarnya (sintaks, pengkodean, angka), bersandar pada standar yang berdekatan yang tepat, dan itu akan terus membayar dividen di seluruh tumpukan dan layanan (RFC 8259, ECMA-404, RFC 6901, RFC 6902, RFC 7386, JSON Schema, JTD, RFC 7464, NDJSON).