Sebuah artikel terperinci yang menelusuri evolusi dari XML ke JSON ke CBOR telah memicu diskusi intens di kalangan developer, dengan banyak yang mempertanyakan apakah CBOR layak mendapat sorotan dan mengkritik pengabaian hubungannya dengan MessagePack. Artikel tersebut, yang memposisikan CBOR sebagai format data yang sangat penting, telah menuai skeptisisme dari komunitas teknis.
Klaim Promosi CBOR Menimbulkan Keraguan
Beberapa developer telah menyatakan kekhawatiran bahwa artikel tersebut lebih terkesan seperti materi pemasaran daripada analisis teknis yang objektif. Kritikus menunjukkan bahwa meskipun XML dan JSON adalah format yang diakui secara universal, menyebut CBOR sebagai format yang sangat penting tampak terlalu dini jika dibandingkan dengan format biner yang lebih mapan seperti Protocol Buffers, Apache Avro, dan Cap'n Proto. Banyak developer mengakui mereka tidak pernah menemui CBOR dalam praktik, dengan salah seorang mencatat bahwa satu-satunya paparan mereka adalah selama pengembangan paspor QR code era COVID.
Waktu dan nada artikel tersebut telah membuat beberapa orang mempertanyakan motivasi di balik promosi format yang masih relatif niche. Namun, pendukung berargumen bahwa peran CBOR dalam standar yang sedang berkembang seperti otentikasi WebAuthn dan FIDO2, di mana ia menangani pertukaran passkey, menunjukkan pentingnya yang semakin meningkat dalam protokol keamanan.
Kasus Penggunaan dan Adopsi CBOR
- WebAuthn/FIDO2: Digunakan untuk pertukaran autentikasi passkey
- Protokol CoAP: Alternatif HTTP ringan untuk perangkat IoT
- COSE: CBOR Object Signing and Encryption untuk keamanan
- Manajemen Perangkat IoT: Protokol OMA-DM/LWM2M
- Representasi Sertifikat: Sertifikat X.509 kompak C509
- Layanan AWS: Mulai mendukung API dengan data berat (2025)
Keunggulan Utama:
- Ukuran pesan lebih kecil dari JSON tanpa kompresi
- Format yang mendeskripsikan diri sendiri (tidak memerlukan skema)
- Dapat diperluas melalui tag semantik terdaftar IANA
- Dioptimalkan untuk lingkungan terbatas/IoT
Hilangnya Koneksi MessagePack Menandakan Red Flag
Kritik signifikan berpusat pada kegagalan artikel untuk mengakui hubungan CBOR dengan MessagePack, format biner sebelumnya yang berbagi tujuan dan prinsip desain yang serupa. Pengabaian ini telah dilabeli sebagai red flag oleh developer berpengalaman yang memahami konteks historis. Hubungan antara format-format ini sangat penting untuk memahami posisi CBOR dalam ekosistem, karena mereka mengatasi masalah serupa dengan pendekatan yang sebanding.
Nah, CBOR adalah MessagePack. Carsten Bormann melakukan fork MessagePack, mengubah beberapa nilai tag, menulis standar di sekitarnya, dan mengirimkannya ke IETF tanpa persetujuan dari pencipta MessagePack.
Konteks historis ini mengungkapkan bahwa CBOR tidak sepenuhnya baru tetapi justru membangun di atas karya yang sudah ada, membuat presentasi artikel berpotensi menyesatkan bagi pembaca yang tidak familiar dengan sejarah format biner.
Perbandingan Kompresi Tidak Ada
Poin perdebatan lain melibatkan kurangnya perbandingan antara CBOR dan JSON yang dikompresi. Meskipun artikel mempromosikan keunggulan ukuran CBOR dibandingkan JSON biasa, artikel tersebut tidak membahas bagaimana performa CBOR dibandingkan JSON dengan teknik kompresi standar seperti gzip atau zstd, yang telah banyak digunakan dan transparan bagi pengguna. Pengabaian ini tampak sangat signifikan mengingat kompresi umumnya digunakan dalam aplikasi web dan dapat secara substansial mempersempit kesenjangan ukuran yang diklaim CBOR sebagai keunggulan.
Ketiadaan perbandingan ini telah membuat beberapa orang menyarankan bahwa hal tersebut sengaja dikecualikan untuk mempertahankan narasi yang menguntungkan bagi CBOR, mirip dengan bagaimana produk pesaing menghindari penyorotan kekuatan kompetitor dalam materi pemasaran mereka.
Perbandingan CBOR vs JSON vs XML
| Fitur | XML | JSON | CBOR |
|---|---|---|---|
| Jenis Format | Bahasa markup untuk dokumen | Format pertukaran data | Format data biner |
| Dapat Dibaca Manusia | Ya | Ya | Tidak |
| Ukuran Pesan | Terbesar (tag yang verbose) | Sedang | Terkecil (encoding biner) |
| Kecepatan Parsing | Paling lambat (parsing kompleks) | Cepat | Tercepat (decoding biner) |
| Dukungan Browser Native | Ya | Ya | Tidak |
| Dukungan Skema | DTD, XSD | JSON Schema | Tag semantik |
| Komentar | Ya | Tidak | Tidak |
| Data Biner | Memerlukan encoding Base64 | Memerlukan encoding Base64 | Dukungan native |
Reality Check Adopsi Format Biner
Meskipun memiliki keunggulan teknis CBOR, diskusi mengungkapkan realitas yang lebih luas tentang adopsi format biner. Banyak developer tetap nyaman dengan keterbacaan manusia JSON dan kemampuan debugging, terutama ketika dikombinasikan dengan infrastruktur kompresi yang sudah ada. Sifat biner CBOR, meskipun efisien, mengorbankan kemampuan untuk dengan mudah memeriksa dan melakukan debug pertukaran data, yang tetap berharga dalam banyak skenario pengembangan.
Beberapa developer mengadvokasi untuk membuat format biner kustom ketika performa sangat penting, berargumen bahwa manfaat kecepatan dari encoding biner cukup substansial untuk membenarkan upaya pengembangan tambahan. Namun, yang lain lebih memilih solusi standar seperti CBOR untuk interoperabilitas dan beban implementasi yang berkurang.
Kesimpulan
Perdebatan seputar artikel yang berfokus pada CBOR ini menyoroti tantangan mempromosikan format data yang lebih baru dalam ekosistem di mana JSON telah mencapai adopsi yang hampir universal. Meskipun CBOR memiliki peran penting dalam lingkungan terbatas dan protokol keamanan, posisinya sebagai penerus umum JSON tampak terlalu dini. Reaksi komunitas menggarisbawahi pentingnya konteks historis yang jujur dan perbandingan komprehensif ketika mengevaluasi format pertukaran data. Seiring Internet of Things terus berkembang, CBOR mungkin menemukan niche-nya, tetapi menggantikan JSON dalam pengembangan web mainstream tetap tidak mungkin mengingat kesederhanaan dan dukungan ekosistem yang dimiliki JSON.
Referensi: From XML to JSON to CBOR