REST API dengan JSON, XML, atau gRPC: Mana yang Tepat untuk Aplikasi Anda?

Saat tim mulai merancang API, pertanyaannya sering berbunyi "pakai REST, JSON, XML, atau gRPC?" Pertanyaan ini sebenarnya mencampur dua keputusan yang berbeda. REST dan gRPC adalah cara mengatur komunikasi antara dua sistem. JSON, XML, dan Protocol Buffers adalah format data yang dikirim di dalam komunikasi itu. REST biasanya dipasangkan dengan JSON, kadang dengan XML, sedangkan gRPC hampir selalu memakai Protocol Buffers. Dengan memisahkan dua pertanyaan ini, pilihannya jadi jauh lebih mudah, dan di kebanyakan proyek jawabannya justru kombinasi, bukan satu pemenang.

Dua Keputusan yang Berbeda

REST adalah gaya arsitektur yang berjalan di atas HTTP biasa. Data disajikan sebagai resource dengan URL, misalnya /orders/10482, dan client mengolahnya dengan method HTTP: GET untuk membaca, POST untuk membuat, PUT atau PATCH untuk mengubah, DELETE untuk menghapus. Server menjawab dengan status code standar seperti 200, 201, 404, atau 422. REST tidak menentukan format data, itulah sebabnya API yang sama bisa mengirim JSON ke satu client dan XML ke client lain.

gRPC, yang awalnya dikembangkan di Google, adalah framework remote procedure call. Alih-alih resource, Anda mendefinisikan service beserta method-nya, misalnya OrderService.GetOrder, di dalam file .proto. Dari file itu, tool akan men-generate kode client dan server untuk Go, Java, Kotlin, Python, C#, Node.js, Dart, dan bahasa lain. gRPC berjalan di atas HTTP/2 dan mengemas pesan dalam Protocol Buffers, format biner yang ringkas. Memanggil service di server lain terasa seperti memanggil fungsi lokal.

REST dengan JSON: Pilihan Default yang Beralasan

Sebagian besar API di internet saat ini, mulai dari payment gateway, marketplace, sampai layanan ekspedisi, memakai REST dengan JSON. Semua bahasa pemrograman bisa membaca JSON, semua browser memahaminya secara bawaan, dan developer bisa mencoba endpoint dengan curl atau Postman lalu langsung membaca hasilnya tanpa tool tambahan. Cache HTTP, CDN, API gateway, dan tool logging juga langsung bisa dipakai.

Kelemahan JSON adalah tidak adanya kontrak bawaan. Tidak ada yang mencegah server mengirim harga sebagai string hari ini dan sebagai angka besok. Tim biasanya mengatasinya dengan menulis spesifikasi OpenAPI dan memvalidasi request serta response terhadap spesifikasi itu, yang sekaligus menghasilkan dokumentasi dan library client. Beberapa hal sebaiknya disepakati sejak awal:

• ID berupa angka besar sebaiknya dikirim sebagai string. JavaScript hanya bisa menyimpan bilangan bulat secara tepat sampai 9.007.199.254.740.991, sehingga ID 64-bit dari database bisa berubah diam-diam saat dibaca di browser.
• Nominal uang sebaiknya dikirim sebagai bilangan bulat dalam satuan terkecil, atau sebagai string desimal, jangan sebagai angka floating point.
• Tanggal sebaiknya memakai format ISO 8601 lengkap dengan offset zona waktu, misalnya 2026-10-30T09:15:00+07:00, supaya server di Singapura dan client di Jakarta sepakat soal jam.
• Format error sebaiknya seragam di semua endpoint. RFC 9457, Problem Details for HTTP APIs, adalah standar siap pakai untuk ini.

XML: Jarang Dipilih, Tapi Sering Diwajibkan

Saat ini hampir tidak ada tim yang memilih XML untuk API baru, tetapi banyak yang tetap harus berurusan dengannya karena pihak lain mewajibkannya. Sistem enterprise dan perbankan yang lebih lama menyediakan web service SOAP, yang pasti berbasis XML. Pesan keuangan bergerak ke ISO 20022, standar berbasis XML yang dipakai Bank Indonesia untuk BI-FAST. Banyak sistem ERP dan aplikasi desktop lama juga bertukar data lewat file XML, sehingga integrasi dengan sistem seperti itu sering kali mau tidak mau berarti membaca dan menulis XML.

XML sebenarnya punya kelebihan nyata. Skema XSD bisa memvalidasi dokumen secara ketat sebelum diproses, namespace memungkinkan beberapa standar digabung dalam satu dokumen, dan XML digital signature bisa menandatangani sebagian isi dokumen. Harganya adalah ukuran yang lebih besar, parsing yang lebih rumit, dan satu risiko keamanan yang terkenal: serangan XML External Entity (XXE), yaitu dokumen yang sengaja dibuat untuk membuat parser membaca file lokal atau memanggil URL internal. Layanan yang menerima XML dari luar wajib mematikan external entity dan pemrosesan DTD di parser-nya.

Pola yang praktis adalah tetap memakai JSON di dalam sistem sendiri, lalu memisahkan urusan XML ke sebuah adapter di bagian tepi: satu modul yang mengubah data internal ke format XML yang diminta mitra atau sistem pemerintah, lengkap dengan test terhadap skema resmi mereka.

gRPC: Dibuat untuk Komunikasi Antar-Service

gRPC paling unggul ketika satu tim memegang kedua sisi koneksi, biasanya antar-microservice di dalam satu platform. File .proto menjadi kontrak yang ketat: kalau service pesanan mengubah tipe sebuah field, kode yang memanggilnya akan gagal saat compile, bukan gagal di production. Protocol Buffers juga dirancang untuk bisa berkembang. Field baru bisa ditambahkan tanpa merusak client lama, selama nomor field yang sudah ada tidak pernah dipakai ulang.

• Empat jenis pemanggilan: satu request dan satu response, stream dari server, stream dari client, dan stream dua arah. Streaming berguna untuk pelacakan lokasi kurir secara live, update progres, atau mengirim data besar dalam potongan-potongan.
• Deadline sudah tersedia bawaan. Client menentukan berapa lama ia mau menunggu, dan batas waktu itu ikut diteruskan ke rantai pemanggilan berikutnya, sehingga satu service yang lambat tidak membuat semua pemanggilnya ikut tertahan.
• Satu koneksi HTTP/2 bisa membawa banyak pemanggilan sekaligus, sehingga overhead koneksi antar-service yang terus-menerus berkomunikasi jadi jauh lebih kecil.
• Client hasil generate berarti tidak ada lagi yang menulis pemanggilan HTTP dan parsing JSON secara manual, dan semua bahasa memakai kontrak yang sama.

Kekurangannya terasa di luar data center. Browser tidak bisa memanggil service gRPC secara langsung; frontend web butuh gRPC-Web lewat proxy seperti Envoy, atau protokol yang kompatibel seperti Connect. Pesannya berbentuk biner, jadi debugging butuh tool seperti grpcurl, tidak bisa sekadar lewat browser atau curl biasa. Selain itu, karena HTTP/2 menjaga koneksi tetap terbuka dalam waktu lama, load balancer yang hanya membagi koneksi, bukan per request, bisa mengirim semua trafik ke satu server saja. Pastikan load balancer, ingress, atau proxy Anda benar-benar mendukung gRPC sebelum memutuskan memakainya.

Seberapa Kecil Protobuf Sebenarnya?

Ukuran data adalah alasan yang paling sering dipakai untuk memilih gRPC, jadi kami mengukurnya. Kami meng-encode pesanan yang sama, sekali dengan tiga item dan sekali dengan seratus item, sebagai JSON ringkas, sebagai XML, dan sebagai Protocol Buffers dengan protoc. Setelah itu masing-masing dikompres dengan gzip, karena begitulah nasib sebagian besar response HTTP di production.

Tanpa kompresi, Protobuf kira-kira setengah ukuran JSON dan sepertiga ukuran XML. Begitu dikompres, sebagian besar selisihnya hilang, dan untuk pesanan yang lebih besar JSON dan Protobuf praktis sama. Keunggulan Protobuf yang sebenarnya ada di tempat lain: CPU yang lebih hemat untuk encode dan decode, yang terasa di service yang melayani ribuan pemanggilan per detik, serta kontrak yang dijaga oleh compiler. Untuk API web atau mobile pada umumnya yang sudah memakai kompresi, alasan bandwidth saja jarang cukup untuk meninggalkan JSON.

Perbandingan Langsung

Jadi, Pakai yang Mana?

• API yang dipakai frontend web, aplikasi mobile, atau developer luar: REST dengan JSON dan spesifikasi OpenAPI. Paling mudah diadopsi pihak lain dan paling mudah di-debug.
• Integrasi yang formatnya ditentukan pihak lain, seperti bank, sistem pemerintah, atau ERP lama: ikuti yang mereka minta, biasanya XML, dan pisahkan dalam adapter tersendiri.
• Banyak service internal dengan bahasa pemrograman berbeda, trafik tinggi, atau kebutuhan streaming: gRPC di antara service-service tersebut.
• Platform yang punya keduanya: gRPC di dalam, lalu gateway REST dan JSON di bagian tepi untuk browser dan mitra. Tool seperti grpc-gateway atau Envoy bisa menerjemahkan keduanya dari definisi .proto yang sama.

Apa pun pilihannya, kebiasaan yang membuat API tetap sehat selalu sama: tulis kontraknya lebih dulu dan simpan di version control, beri versi baru untuk perubahan yang merusak alih-alih menyelipkannya diam-diam, pasang timeout di setiap pemanggilan, buat endpoint pembayaran dan pesanan idempotent supaya retry tidak membuat pelanggan tertagih dua kali, dan catat log yang cukup untuk menelusuri satu request lintas service. Jika Anda sedang merencanakan API atau integrasi sistem dan butuh pendapat kedua soal desainnya, tim kami membangun dan merawat sistem seperti ini untuk klien setiap hari.