Format Data dalam REST API: Bahasa yang Dipahami oleh Mesin dan Manusia

Pernah gak, kamu kirim request ke sebuah REST API—misalnya GET /users/123—dan nungguin respons dari server, berharap muncul data user lengkap dengan nama, email, dan status aktif?

Tapi… gak muncul apa-apa. Atau lebih parah: muncul error.

Padahal secara logika, kamu udah “ngomong” ke server.
Udah ketik endpoint-nya, udah kirim request-nya.
Jadi apa yang salah?

Nah, ternyata ada satu hal yang kadang luput: kamu belum sepakat sama server soal bahasanya.

Iya, betul. REST API itu seperti dua orang asing yang baru ketemu.
Mereka bisa aja saling bantu, tapi cuma kalau punya bahasa yang sama.

“Mau ngobrol? Boleh. Tapi ngomongnya pakai format apa, nih?”

Karena REST itu bukan sekadar ngirim permintaan dan dapet jawaban.
REST itu komunikasi. Dan seperti semua komunikasi yang sehat, perlu aturan main—perlu bahasa yang dimengerti kedua belah pihak.

• Client bisa datang dari mana aja:
• Sistem IoT di pabrik,
• Web app startup kecil,

Sampai backend milik perusahaan besar.

Tapi mereka semua, kalau mau ngobrol sama satu server REST yang sama, harus bisa “bicara” dalam format yang dipahami server.

Nah, dari sinilah kita mulai berkenalan dengan satu hal yang sering terdengar sepele, tapi sebenarnya penting banget di dunia REST: format data.

Format data itu semacam kesepakatan bahasa antara client dan server.
Tanpa itu, komunikasi jadi seperti ngobrol lintas planet—pesan dikirim, tapi gak ada yang ngerti maksudnya.

Bukan cuma soal menyampaikan data, tapi juga bagaimana data itu bisa dibaca, dimengerti, lalu dijawab balik dengan benar.
Client bilang: “Ini datanya.”
Server bilang: “Oke, aku tahu harus diapain.”

Tapi coba kirim data dengan format yang gak dikenali?
Server bisa cuma diem, kasih error, atau lebih sering: nulis log panjang yang bikin kamu makin bingung.

“Unexpected token di baris 1… apa lagi ini maksudnya?”

Kamu pun akhirnya buka Postman sambil nyengir getir, lalu nyeletuk ke teman satu tim:

“Bro, ini JSON-nya yang salah atau server-nya yang ngambek, ya?”

Dan begitulah.
Kesalahan kecil di format bisa bikin obrolan antara client dan server berubah jadi debat satu arah.

REST Butuh Format yang Seragam

Bayangin REST API itu kayak meja resepsionis di gedung publik.
Mejanya terbuka. Siapa pun boleh datang—frontend dari browser, aplikasi mobile, IoT dari pabrik, bahkan bot dari sistem backend lain.

Tapi resepsionisnya (alias server) gak bisa nebak-nebak maksud tamu.

“Mas, saya mau ambil data user.”
“User yang mana? Format datanya mana? Ini berantakan semua…”

Nah, itulah kenapa REST butuh format yang seragam dan terstruktur.
Format data adalah cara kita menyampaikan informasi secara jelas: siapa, mau apa, dan dalam bentuk seperti apa.

Kamu gak bisa asal ngirim data mentah lalu berharap server ngerti sendiri.
REST bukan cenayang.
REST butuh data yang rapi, berformat, dan sesuai aturan main.

Dan di dunia REST yang modern, dua format paling sering dipakai adalah:
JSON dan XML.
Keduanya punya gaya bicara masing-masing—satu santai dan ringkas, satunya lagi formal dan lengkap.

JSON — Sang Bintang Utama

Kalau REST itu pesta, JSON adalah tamu yang paling akrab dengan semua orang.
Datangnya cepat, gak ribet, dan semua orang bisa ngobrol pakai bahasanya.

JSON (JavaScript Object Notation) jadi pilihan utama karena:

• Ringkas dan mudah dibaca (bahkan untuk mata manusia biasa)
• Formatnya mirip object di JavaScript, Python, PHP, dan bahasa lain
• Ringan dikirim lewat jaringan (hemat bandwidth)
• Gampang diolah di frontend maupun backend

Contoh JSON:

{
  "name":"Luna",
  "role":"Assistant",
  "active":true
}

Kalau kamu ngirim data dengan format kayak gitu, REST API langsung ngerti:

“Oke, ini objek user. Ada nama, peran, dan statusnya. Siap diproses.”

JSON sudah seperti bahasa sehari-hari di dunia REST API.
Saking umumnya, banyak developer bahkan lupa kalau ada format lain.
Tapi jangan salah—ada veteran yang lebih dulu hadir dan masih sering muncul di balik layar.

XML — Sang Veteran yang Masih Bertugas

Sebelum JSON jadi primadona, dunia API pernah dikuasai oleh satu nama besar: XML.
Dan sampai sekarang, XML masih aktif bertugas, terutama di dunia yang sedikit lebih formal dan konservatif—seperti sistem keuangan, pemerintahan, dan enterprise.

Contoh XML:

<user>
  <name>Luna</name>
  <role>Assistant</role>
  <active>true</active>
</user>

Kalau dilihat sekilas, XML ini kayak saudara tua yang suka menulis lengkap—semua dibuka dan ditutup dengan tag.
Lebih verbose? Iya.
Tapi justru itu yang bikin XML cocok untuk:

• Dokumen kompleks yang butuh struktur formal
• Validasi data ketat (pakai XSD atau DTD)
• Sistem integrasi yang sudah lama jalan dan gak bisa diganti sembarangan

XML juga masih hidup dengan baik di dunia SOAP (pendahulu REST), dan banyak sistem lawas yang masih setia padanya.

Tapi untuk aplikasi modern yang butuh respons cepat, ringan, dan simple—XML sering dianggap terlalu banyak basa-basi.

Format Lain: Masih Ada, Tapi Jarang

Selain JSON dan XML, ada beberapa format lain yang kadang dipakai dalam REST API:

• YAML — Mudah dibaca manusia, populer di konfigurasi (contoh: GitHub Actions), tapi jarang dipakai untuk REST response.
• Form-Encoded (application/x-www-form-urlencoded) — Sering dipakai untuk POST dari form HTML klasik.
• Multipart/Form-Data — Digunakan saat kamu upload file atau kirim data campuran (file + teks).
• Plain Text — Untuk response sederhana atau error message yang gak perlu format kompleks.
• Protocol Buffers / MessagePack — Format biner yang super efisien, tapi biasanya dipakai di sistem non-REST seperti gRPC.

Server Bisa Terima Apa Saja, Tapi Kamu Harus Jelas

REST itu sebenarnya cukup fleksibel.
Mau pakai JSON, XML, bahkan plain text pun—selama server mendukung, dia siap melayani.
Tapi ingat: server bukan cenayang, bukan penerjemah otomatis, dan bukan pembaca pikiran.

Jadi, sebelum kamu minta sesuatu dari server, kamu perlu jelaskan dulu dua hal penting:

1. Data yang kamu kirim dalam format apa?
2. Kamu mau dibalas pakai format apa?

Dan cara kamu menyampaikannya adalah lewat HTTP headers—tepatnya di Content-Type dan Accept.

Contohnya begini:

Content-Type: application/json
Accept: application/json

Artinya:

“Saya akan mengirim data dalam format JSON, dan saya juga ingin respons balik dari kamu dalam format JSON, ya.”

Kalau kamu pakai:

Accept: application/xml

Maka kamu sedang bilang:

“Kalau bisa, tolong balas saya pakai XML ya. Saya ngerti bahasanya.”

Dan server, kalau dia memang mendukung XML, akan membalas dengan data XML.
Kalau nggak? Bisa jadi dia balas dalam format default (biasanya JSON), atau malah kasih status 406 Not Acceptable.

Gampangnya, REST API itu kayak meja layanan yang bisa bicara banyak bahasa.
Tapi kamu harus bilang dulu:

“Saya kirim data pakai Bahasa JSON.”
“Dan saya paham balasan dalam Bahasa XML atau JSON, terserah kamu.”

Kalau kamu gak bilang apa-apa, server bisa bingung:

“Dia ngerti bahasa apa, ya? Saya bales pakai JSON aja deh, semoga nyambung.”

Dan di sinilah banyak error kecil bisa terjadi—bukan karena kode kamu salah, tapi karena komunikasinya gak jelas.

Jadi meskipun REST itu fleksibel, dia tetap butuh kamu ngomong dengan sopan dan terang-terangan.

Karena komunikasi yang baik di dunia API—sama seperti di dunia nyata—selalu dimulai dari:

"Aku pakai bahasa ini. Kamu ngerti gak?"

Mana yang Harus Dipilih?

Format	Keunggulan	Kapan Cocok Digunakan
JSON	Ringan, populer, mudah dibaca dan ditulis	Hampir semua REST API modern
XML	Kuat, formal, cocok untuk validasi dokumen	Sistem lama, enterprise, SOAP
Form	Simpel, didukung form HTML	Login form, web form lawas
Multipart	Perlu upload file dan data sekaligus	Upload gambar, CV, dll
YAML	Lebih enak dibaca, tapi bukan untuk REST	Konfigurasi, dokumentasi, bukan response

Penutup: Yang Penting Kita Sepakat di Awal

Format data di REST itu ibarat bahasa yang kita pilih sebelum mulai ngobrol.
Gak harus sama setiap saat, gak harus yang paling populer—yang penting: disepakati bersama.

JSON, XML, atau format lain bukanlah inti dari segalanya.
Mereka cuma alat bantu—cara agar dua pihak yang berbeda platform, bahasa, atau bahkan generasi, bisa tetap terhubung dan saling memahami.

REST gak pernah memaksa satu jalan.
Dia cuma minta satu hal kecil:

“Kalau mau komunikasi lancar, yuk sama-sama jujur dari awal. Kasih tahu kamu ngomong pakai bahasa apa, dan kamu pengen dibales pakai bahasa apa juga.”

Kalau itu dilakukan,
semua proses jadi lebih mulus.
Server gak perlu nebak, client gak perlu frustasi.

Dan begitu kamu paham soal ini,
kamu sebenarnya sudah menyentuh inti dari filosofi REST itu sendiri:
bukan sekadar soal ngirim data dengan benar, tapi soal membangun komunikasi yang bisa dimengerti dua arah—tanpa asumsi, tanpa tebak-tebakan.