Lompat ke konten
Aback Tools Logo

MessagePack vs JSON: Ukuran, Kecepatan dan Overhead Dibandingkan

MessagePack vs JSON dibandingkan: dari mana penghematan ukuran 20-50% berasal, kecepatan serialisasi per runtime, perbedaan sistem tipe, dan kapan trade-off ini layak.

DH
12 menit baca2,750 kata

JSON adalah lingua franca API web - mudah dibaca, universal, dan didukung di mana-mana. MessagePack adalah format serialisasi biner yang dirancang membawa data yang sama dengan 20-50% lebih sedikit byte, dengan parsing lebih cepat di kedua sisi. Memahami persis dari mana penghematan ukuran itu berasal, apa yang Anda korbankan, dan kapan trade-off ini layak menjadi pembeda antara optimasi prematur dan peningkatan infrastruktur yang terukur.

20-50%Lebih kecil dari JSON terminifikasiPenghematan payload tipikal
2-4×Serialisasi lebih cepatvs parsing JSON teks
< 1sWaktu perbandingan ukuranUntuk payload JSON apa pun

Apa itu MessagePack?

MessagePack adalah format serialisasi biner yang dibuat oleh Sadayuki Furuhashi pada 2008 dan diterbitkan sebagai spesifikasi terbuka. Format ini mengodekan tipe data yang sama seperti JSON - null, boolean, integer, float, string, array, map - tetapi memakai representasi biner yang padat alih-alih teks yang bisa dibaca manusia. Boolean `true` yang memakan 4 byte sebagai teks JSON hanya menempati 1 byte di MessagePack. Bilangan bulat kecil seperti 42 memakan 3 byte di JSON dan 1 byte di MessagePack.

Format ini tanpa skema: seperti JSON, ia tidak memerlukan skema yang telah ditentukan untuk mengodekan atau mendekodekan data. Karena itu ia menjadi pengganti langsung JSON di sebagian besar konteks API - Anda mengganti serializer tanpa mengubah model data. MessagePack didukung luas dengan pustaka resmi dan komunitas di Python, JavaScript, Go, Ruby, Java, C++, Rust, dan lebih dari 50 bahasa lainnya.

Bagaimana pengodean MessagePack bekerja

  • Byte tag tipe - setiap nilai dimulai dengan tag 1 byte yang mengodekan tipe dan, untuk nilai kecil, nilai itu sendiri (fixint, fixstr, fixarray, fixmap).
  • Bilangan bulat - bilangan bulat kecil (0-127) memakan total 1 byte. Bilangan bulat lebih besar memakai 2, 4, atau 8 byte sesuai besarnya, selalu lebih kecil daripada representasi teks desimalnya.
  • String - dikodekan sebagai urutan byte UTF-8 dengan awalan panjang. String pendek (≤31 karakter) memakai header 1 byte; string lebih panjang memakai header 2 atau 4 byte.
  • Boolean dan null - masing-masing menempati tepat 1 byte. Di JSON, `true` berukuran 4 byte, `false` 5 byte, dan `null` 4 byte.
  • Array dan map - dengan awalan panjang; array kecil (≤15 elemen) memakai 1 byte overhead dibandingkan tanda `[` `]` dan koma pada JSON.

Note

MessagePack bukan algoritme kompresi - ia tidak menerapkan LZ77, pengodean Huffman, atau bentuk kompresi entropi apa pun. Penghematan ukuran sepenuhnya berasal dari penggunaan pengodean biner tipe yang padat alih-alih karakter teks. Menerapkan kompresi gzip atau Brotli di atas MessagePack menambah penghematan lebih lanjut, tetapi JSON yang dikompresi sebagai teks sering menutup selisihnya secara signifikan karena nama kunci JSON yang berulang sangat mudah dikompresi.

Perbandingan ukuran: seberapa kecil MessagePack?

Penghematan ukuran dari berpindah ke MessagePack sepenuhnya bergantung pada komposisi data payload Anda. Payload dengan banyak bidang numerik, boolean, dan nilai null mendapat keuntungan terbesar. Payload yang didominasi string - teks panjang, UUID, tanggal ISO - mendapat keuntungan lebih kecil karena isi string itu sendiri disimpan sebagai byte UTF-8 mentah di kedua format.

Penghematan berasal dari informasi tipe dan overhead struktural, bukan dari mengompresi nilai datanya. String sepanjang 200 karakter berbiaya kurang lebih sama di kedua format.

- Rasional spesifikasi MessagePack

Perbandingan ukuran menurut tipe data

NilaiByte JSON (terminifikasi)Byte MessagePackPenghematan
true4175%
false5180%
null4175%
42 (integer)2150%
1000 (integer)4250%
"hello"7614%
"2026-06-11"12118%

Benchmark payload dunia nyata

Respons REST API tipikal dengan tipe data campuran - ID, nama, stempel waktu, flag status, dan penghitung - mengalami pengurangan ukuran 20-35%. Payload berisi data numerik murni (pembacaan sensor, peristiwa analitik) dapat mencapai pengurangan 40-50%. Payload yang sebagian besar berisi string panjang (isi artikel, pesan log) mungkin hanya berkurang 5-15%. Alat Perbandingan Ukuran JSON vs MessagePack di Aback Tools mengukur penghematan byte persis untuk payload JSON tertentu - tempelkan payload produksi Anda dan baca persentase sebenarnya dalam waktu kurang dari satu detik.

Tip

Sebelum memutuskan mengadopsi MessagePack, ukur penghematan ukuran pada payload produksi Anda yang sebenarnya, bukan pada benchmark sintetis. Payload dengan nama kunci panjang yang berulang - umum pada desain API yang bertele-tele - sangat mudah dikompresi dengan gzip. Kadang JSON yang dikompresi gzip lebih kecil daripada MessagePack tanpa kompresi. Selalu bandingkan gzip+JSON dengan gzip+MessagePack untuk evaluasi yang adil.

Perbandingan Ukuran JSON vs MessagePack

Tempelkan payload JSON apa pun dan lihat ukuran byte MessagePack-nya, persentase penghematan persis, rincian per tipe, dan pratinjau heksadesimal - lokal di browser, tanpa unggah.

Open tool

Kecepatan serialisasi: seberapa cepat MessagePack?

Serialisasi dan deserialisasi MessagePack biasanya 2-4x lebih cepat daripada pemrosesan JSON teks standar dalam benchmark. Keunggulan kecepatan berasal dari melewati tokenisasi UTF-8: parser JSON harus memindai setiap byte mencari karakter struktural (kurung kurawal, tanda kutip, koma, titik dua), sedangkan parser MessagePack membaca tag tipe lalu melompat langsung ke batas nilai berikutnya. Tidak ada pemindaian tanda kutip, tidak ada penanganan escape, tidak ada konversi string angka menjadi bilangan bulat.

Konteks kinerja per bahasa

Selisih kecepatan sangat bervariasi menurut runtime. Di Python, `msgpack` 3-5x lebih cepat daripada modul `json` standar untuk payload tipikal. Namun, `orjson` (pustaka JSON Python dengan inti Rust) hampir secepat `msgpack` pada banyak beban kerja - selisihnya menyusut menjadi 1,2-1,5x. Di Node.js, `@msgpack/msgpack` mengungguli `JSON.parse` bawaan sekitar 2x. Di Go, selisihnya lebih kecil lagi karena `encoding/json` standar Go sudah cukup cepat.

Di mana kecepatan paling penting

Manfaat kecepatan serialisasi paling berarti pada komunikasi internal antar-mikroservis dengan throughput tinggi, tempat layanan bertukar ribuan pesan per detik dan serialisasi menjadi biaya CPU yang terukur. Untuk API web biasa yang melayani beberapa ratus permintaan per detik, selisih waktu serialisasi antara JSON dan MessagePack dapat diabaikan dibandingkan waktu kueri basis data atau latensi jaringan. Profil dulu hambatan Anda yang sebenarnya sebelum mengoptimalkan serialisasi.

Note

Di banyak sistem produksi, biaya dominan bukanlah waktu serialisasi melainkan waktu transmisi payload. Beralih dari JSON tanpa kompresi ke MessagePack mengurangi waktu transmisi secara proporsional dengan pengurangan ukurannya. Mengaktifkan HTTP/2 dan kompresi gzip pada API JSON Anda yang ada sering memberi peningkatan throughput yang serupa atau lebih besar tanpa perubahan kode sama sekali.

Perbedaan sistem tipe antara MessagePack dan JSON

MessagePack dan JSON berbagi himpunan tipe inti yang sama - null, boolean, number, string, array, dan object/map - tetapi MessagePack lebih kaya pada tingkat numerik dan biner. Perbedaan ini penting saat Anda memigrasikan API JSON yang ada atau merancang protokol baru, karena sebagian tipe MessagePack tidak memiliki padanan langsung di JSON.

Tipe yang ditambahkan MessagePack di luar JSON

  • Bilangan bulat 64-bit tanpa tanda - JSON sama sekali tidak punya tipe bilangan bulat (angka adalah double IEEE 754 yang kehilangan presisi di atas 2^53). MessagePack mengodekan nilai uint64 dengan tepat.
  • Array byte biner - MessagePack memiliki tipe bin asli untuk urutan byte mentah. JSON tidak punya padanannya - data biner harus dikodekan base64 sebagai string, menambah overhead sekitar 33%.
  • Tipe ekstensi - mekanisme khusus untuk tipe spesifik aplikasi seperti stempel waktu (ext type 1), desimal, dan data bertag khusus. Memungkinkan pengayaan semantik tanpa skema.
  • Float32 - MessagePack dapat mengodekan float 32-bit (4 byte). JSON selalu memakai representasi teks presisi ganda 64-bit, yang lebih besar dan kehilangan informasi tipe f32.

Masalah bolak-balik tipe

Jebakan kritis saat bermigrasi dari JSON ke MessagePack: JSON hanya punya satu tipe angka (double IEEE 754), sedangkan MessagePack membedakan int8, int16, int32, int64, uint8-uint64, float32, dan float64. Jika aplikasi Anda menyerialkan angka JSON lalu mendeserialkannya sebagai MessagePack, tipenya bisa berubah. Nilai seperti 42 yang diserialkan dari JavaScript (sebagai double) bisa terdeserialkan di bahasa bertipe ketat sebagai uint8. Selalu verifikasi perilaku bolak-balik antara pustaka serialisasi Anda dan layanan yang mengonsumsinya.

FiturJSONMessagePack
Dapat dibaca manusia✓ Ya✗ Hanya biner
Tipe bilangan bulat✗ Tidak ada (double)✓ int8-int64, uint8-uint64
Data biner✗ Perlu base64✓ Tipe bin asli
Bilangan bulat 64-bit✗ Kehilangan presisi✓ uint64/int64 penuh
Perlu skema✗ Tanpa skema✗ Tanpa skema
Bawaan browser✓ JSON.parse/stringify✗ Perlu pustaka
Dukungan streaming✓ Ya✓ Ya (dengan pustaka)
Tipe ekstensi✗ Tidak✓ Ya (tipe ext)

Stempel waktu MessagePack

Tipe ekstensi 1 MessagePack adalah format stempel waktu terstandardisasi yang mengodekan waktu Unix sebagai nilai biner 4, 8, atau 12 byte dengan presisi nanodetik. Ini lebih kecil dan lebih presisi daripada string ISO 8601 seperti `"2026-06-11T14:30:00Z"` (20 byte sebagai JSON) dan menghindari ambiguitas zona waktu. Sebagian besar pustaka MessagePack secara otomatis mengodekan dan mendekodekan tipe ekstensi ini, sehingga penanganan stempel waktu menjadi transparan bagi lapisan aplikasi.

Kapan menggunakan MessagePack vs JSON

Pilihan antara MessagePack dan JSON bukan soal format mana yang "lebih baik" - melainkan soal kendala mana yang penting dalam konteks tertentu. JSON unggul dalam universalitas, tooling, dan kemampuan debug. MessagePack unggul dalam ukuran payload dan kecepatan parsing. Sebagian besar API sebaiknya memulai dengan JSON dan bermigrasi ke MessagePack hanya setelah profiling memastikan bahwa serialisasi atau ukuran payload memang hambatan nyata.

Gunakan MessagePack ketika

  • Komunikasi antar-mikroservis internal - layanan yang Anda kendalikan di kedua ujung, tempat keterbacaan manusia tidak diperlukan dan throughput menjadi perhatian yang terukur.
  • Broker pesan frekuensi tinggi - topik Kafka, NATS, RabbitMQ yang membawa ribuan peristiwa per detik tempat ukuran payload berdampak langsung pada throughput dan biaya penyimpanan.
  • API seluler dengan bandwidth terbatas - mengurangi ukuran payload 30% pada API seluler bertrafik tinggi secara nyata mengurangi pemakaian data dan latensi di koneksi seluler.
  • Protokol game real-time atau IoT - tempat frame biner, latensi di bawah satu milidetik, dan efisiensi bandwidth menjadi persyaratan desain sejak awal.
  • Transport data biner - payload berisi byte mentah (gambar, potongan audio, materi kriptografi) menghindari overhead base64 33% dari pengodean JSON.

Tetap pakai JSON ketika

  • API publik - konsumen eksternal mengharapkan JSON; menambahkan MessagePack memerlukan adopsi pustaka di sisi klien dan middleware negosiasi konten.
  • Tooling untuk pengembang - DevTools browser, curl, Postman, dan penjelajah API semuanya bekerja asli dengan JSON; men-debug MessagePack memerlukan langkah dekode tambahan.
  • Endpoint bertrafik rendah - biaya rekayasa untuk menambahkan dukungan MessagePack jauh melebihi manfaatnya ketika volume payload kecil.
  • Sudah memakai kompresi gzip - gzip HTTP atau Brotli mengompresi nama kunci JSON yang berulang secara agresif, sering mencapai pengurangan payload serupa dengan MessagePack mentah.

Warning

Negosiasi konten adalah jalur migrasi yang disarankan untuk API JSON yang ada: server menerima Accept: application/json maupun Accept: application/msgpack, lalu merespons dalam format yang diminta klien. Ini memungkinkan adopsi bertahap tanpa merusak klien yang ada. Jangan mengubah API publik yang ada menjadi MessagePack secara eksklusif - biaya debug dan tooling bagi konsumen eksternal jarang sepadan dengan penghematan ukurannya.

Integrasi dan tooling

MessagePack memiliki dukungan pustaka yang matang di semua bahasa utama, tetapi tidak didukung secara asli di browser atau framework HTTP standar seperti JSON. Menambahkan MessagePack ke stack yang ada berarti menambah dependensi, memperbarui penanganan content-type, dan memperbarui semua tooling debug atau logging yang mengonsumsi body permintaan/respons mentah.

Dukungan pustaka menurut bahasa

  • Python - `msgpack` (PyPI). Ekstensi C cepat dengan fallback Python murni. Pengganti langsung `json` di sebagian besar kasus.
  • JavaScript / Node.js - `@msgpack/msgpack` (npm). Asli TypeScript, mendukung streaming. Ada juga `msgpackr` untuk kinerja lebih tinggi.
  • Go - `github.com/vmihailenco/msgpack` atau `github.com/ugorji/go/codec`. Keduanya mengimplementasikan spesifikasi lengkap dengan dukungan tipe ekstensi.
  • Java / JVM - `msgpack-java` (resmi). Terintegrasi dengan Jackson lewat `jackson-dataformat-msgpack` sebagai pengganti langsung JSON.
  • Rust - `rmp` dan `rmp-serde`. Serialisasi berbasis Serde membuat penambahan MessagePack di samping JSON yang ada menjadi perubahan satu baris.

Memvalidasi payload sebelum mengodekan

Sebelum mengalihkan API produksi ke MessagePack, validasi struktur JSON yang Anda kodekan. Payload JSON dengan kesalahan struktural - koma di akhir, kunci tanpa tanda kutip, null yang tak terduga - akan diam-diam menghasilkan keluaran MessagePack yang cacat dan menyebabkan kesalahan dekode yang membingungkan di sisi konsumen. Jalankan payload Anda melalui JSON Formatter Viewer untuk memeriksa struktur dan JSON Schema Validator untuk memastikan formatnya sesuai dengan bentuk yang diharapkan sebelum mengodekan.

Kompresor JSON

Jelajahi opsi pengurangan payload JSON - perbandingan dengan MessagePack, pemendekan kunci, dan terminifikasi - semuanya lokal di browser tanpa unggah.

Open tool

Trade-off dan catatan penting

MessagePack bukan peningkatan gratis dari JSON. Format biner membawa biaya nyata pada kemampuan debug, kompatibilitas tooling, dan onboarding pengembang. Ini bukan kekhawatiran hipotetis - inilah alasan utama sebagian besar tim yang mengevaluasi MessagePack akhirnya tetap memakai JSON untuk semuanya kecuali kanal internal bervolume tinggi tertentu yang membuat trade-off-nya jelas sepadan.

Kemampuan debug adalah biaya praktis terbesar

Dengan JSON, Anda bisa membaca body permintaan mentah di terminal, DevTools browser, atau log teks apa pun. Dengan MessagePack, Anda melihat keluaran biner seperti `\x81\xa4name\xa5Alice`. Setiap sesi debug memerlukan langkah dekode. Tim yang memakai MessagePack di produksi biasanya menambahkan utilitas dekode khusus ke tooling internal mereka dan mencatat payload hasil dekode di stack observabilitas bersama frame binernya. Gesekan pengembangan itu nyata - jangan meremehkannya.

Evolusi skema dan versi

MessagePack tanpa skema seperti JSON, jadi menambah atau menghapus bidang tidak merusak formatnya. Namun, ketiadaan skema berarti tidak ada mekanisme kompatibilitas mundur bawaan selain pemeriksaan bidang di tingkat aplikasi. Untuk API yang terus berkembang, tipe ekstensi MessagePack dapat membawa metadata versi skema, tetapi ini memerlukan desain eksplisit. Untuk protokol bertipe ketat yang berkembang, evolusi skema berbasis nomor bidang pada Protobuf lebih andal - lihat perbandingan JSON Schema vs Protobuf untuk analisis trade-off lengkapnya.

Ekualiser gzip

Kompresi gzip HTTP sering menutup selisih antara JSON dan MessagePack secara drastis. API JSON dengan kunci berulang di seluruh elemen array sangat mudah dikompresi karena gzip memanfaatkan pengulangan itu. Respons API tipikal yang 40% lebih kecil sebagai MessagePack mentah mungkin hanya 5-10% lebih kecil setelah kedua format dikompresi gzip. Selalu ujicoba MessagePack terkompresi terhadap JSON terkompresi sebelum memutuskan migrasi.

Warning

Jangan pernah mengadopsi MessagePack sebagai perubahan menyeluruh di seluruh API tanpa profiling. Ukur ukuran payload dan waktu serialisasi pada payload produksi Anda yang sebenarnya menggunakan alat [Perbandingan Ukuran JSON vs MessagePack](/tools/compress/json-compressors/json-vs-messagepack). Lalu ukur payload yang sama setelah kompresi gzip. Lanjutkan hanya jika perbandingannya menunjukkan peningkatan berarti yang sepadan dengan biaya debug.

Key takeaways

  • MessagePack 20-50% lebih kecil daripada JSON terminifikasi pada payload tipikal - penghematan persisnya bergantung pada berapa banyak bilangan bulat, boolean, dan nilai null yang dikandung payload.
  • Kecepatan serialisasi 2-4x lebih cepat daripada JSON teks dalam benchmark, tetapi pustaka JSON berkinerja tinggi seperti orjson (Python) dan simdjson (C++) memperkecil selisih ini secara signifikan.
  • MessagePack menambahkan tipe asli yang tidak dimiliki JSON: bilangan bulat 64-bit tanpa tanda, data biner mentah, float32, dan tipe ekstensi untuk stempel waktu dan data kustom.
  • Trade-off praktis terbesar adalah kemampuan debug - keluaran MessagePack bersifat biner dan tidak dapat dibaca langsung di DevTools, curl, atau log tanpa langkah dekode.
  • JSON yang dikompresi gzip sering menutup selisih ukuran dengan MessagePack tanpa kompresi - selalu uji keduanya di bawah gzip sebelum bermigrasi.
  • Alat Perbandingan Ukuran JSON vs MessagePack di Aback Tools mengukur penghematan byte persis dan rincian per tipe untuk payload JSON apa pun dalam waktu kurang dari satu detik.
  • Kasus penggunaan terbaik adalah mikroservis internal bertrafik tinggi, broker pesan, API seluler dengan bandwidth terbatas, dan payload berisi data biner mentah.

Pertanyaan yang sering diajukan

MessagePack biasanya 20-50% lebih kecil daripada JSON terminifikasi. Penghematan persisnya bergantung pada bentuk payload Anda. Payload dengan banyak bilangan bulat, boolean, dan nilai null paling agresif dikompresi - bilangan bulat kecil (0-127) berukuran 1 byte di MessagePack versus 1-3 byte pada teks JSON. Payload yang didominasi string panjang mendapat keuntungan lebih kecil karena string disimpan sebagai byte UTF-8 mentah di kedua format. Gunakan alat Perbandingan Ukuran JSON vs MessagePack di Aback Tools untuk mengukur penghematan persis pada payload Anda.

Serialisasi dan deserialisasi MessagePack biasanya 2-4x lebih cepat daripada pemrosesan JSON teks dalam benchmark, karena parsing biner melewati tokenisasi UTF-8 per karakter yang dibutuhkan JSON. Keunggulan kecepatan sebenarnya di produksi sangat bergantung pada runtime dan pustaka - parser JSON berkinerja tinggi (simdjson di C++, orjson di Python) memperkecil selisih ini secara signifikan. Manfaat performa paling terasa pada API mikroservis bertrafik tinggi yang memproses ribuan permintaan per detik.

MessagePack mendukung semua tipe yang kompatibel dengan JSON: null, boolean, integer (bertanda dan tanpa tanda hingga 64-bit), float (32 dan 64-bit), string UTF-8, array byte biner, array, dan map. Ia juga mendukung mekanisme tipe ekstensi untuk tipe kustom seperti stempel waktu, desimal, dan data spesifik aplikasi. Berbeda dari JSON, MessagePack membedakan string dan data biner mentah pada tingkat sistem tipe - sesuatu yang tidak dapat diungkapkan JSON tanpa pengodean base64.

Bisa. Paket npm @msgpack/msgpack menyediakan encoder dan decoder MessagePack yang kompatibel dengan browser dengan dukungan TypeScript lengkap. Namun, MessagePack adalah format biner: tidak dapat digunakan dengan localStorage browser (yang hanya menyimpan string), dikirim sebagai body teks biasa, atau dicatat dalam bentuk terbaca tanpa penampil heksadesimal. Untuk komunikasi browser-ke-server, setel header Content-Type ke application/msgpack dan pastikan kedua sisi memakai versi pustaka yang sama agar pengodeannya konsisten.

Untuk payload sangat kecil (di bawah 20 byte), MessagePack bisa berukuran sama atau sedikit lebih besar daripada JSON terminifikasi. Hal ini terjadi karena tag tipe MessagePack menambah 1 byte per nilai, dan untuk payload mungil overhead tipe itu melebihi kepadatan pengodean binernya. Untuk payload satu bidang seperti {"ok":true}, JSON berukuran 10 byte dan MessagePack sekitar 8-9 byte - perbedaannya dapat diabaikan. Keunggulan ukurannya tumbuh signifikan seiring kompleksitas dan ukuran payload.

Tidak. MessagePack adalah format biner - keluaran terenkode tidak dapat dibaca tanpa decoder khusus atau penampil heksadesimal. Ini salah satu trade-off utama dibanding JSON. Selama pengembangan, men-debug payload MessagePack memerlukan alat yang mendekode biner kembali ke representasi yang terbaca. Alat Perbandingan Ukuran JSON vs MessagePack di Aback Tools menampilkan 64 byte pertama keluaran MessagePack dalam heksadesimal, yang berguna untuk memverifikasi kebenaran pengodean tanpa langkah dekode penuh.

Ya, tetapi memerlukan konfigurasi eksplisit di klien dan server. Klien harus menyetel header Accept: application/msgpack dan Content-Type: application/msgpack, dan server harus menangani JSON maupun MessagePack demi kompatibilitas mundur. Sebagian besar framework REST (Express, FastAPI, Spring) mendukung middleware negosiasi konten kustom. Ekosistem GraphQL dan OpenAPI umumnya mengasumsikan JSON: menambahkan MessagePack memerlukan serializer khusus dan jarang sepadan dengan biaya rekayasanya kecuali ukuran payload merupakan hambatan yang terukur.

Ketiganya adalah format serialisasi biner yang lebih padat daripada JSON. Protobuf (dari Google) memakai definisi skema untuk menghilangkan nama bidang sepenuhnya dan mencapai kompresi 5-10x dibanding JSON - kepadatan tertinggi di antara ketiganya, tetapi mengharuskan pemeliharaan berkas .proto. MessagePack tanpa skema seperti JSON, menjadikannya pengganti langsung tanpa overhead skema. CBOR (RFC 7049) adalah standar IETF dengan lebih banyak tipe data dan ekstensibilitas lebih baik daripada MessagePack. Untuk memigrasikan API dari JSON dengan gesekan minimal, MessagePack adalah titik awal paling mudah.

ShareXLinkedIn