JSON Array vs Object: Kapan Pakai Yang Mana?

Oleh Andi Putra Ogie · Update: Juli 2026 · 8 menit baca

Pertanyaan yang kelihatannya sepele tapi sering bikin developer pemula bingung: kapan sebaiknya data direpresentasikan sebagai array [...], dan kapan sebagai object {...}? Keduanya sama-sama bisa "menampung banyak item", tapi punya semantik dan implikasi teknis yang cukup berbeda. Pilihan yang salah bisa bikin API sulit dipakai, rawan bug, atau sulit di-extend di masa depan.

Perbedaan Mendasar

Array adalah koleksi terurut (ordered) yang diakses berdasarkan posisi/index. Object adalah koleksi key-value yang diakses berdasarkan nama key, dan secara semantik dianggap tidak terurut (meskipun dalam praktiknya banyak parser modern mempertahankan urutan insersi, ini bukan jaminan yang bisa diandalkan across semua implementasi). Perbedaan konseptual ini bukan sekadar detail teknis — ia langsung mempengaruhi bagaimana consumer API menulis kode untuk mengakses data tersebut, dan seberapa mudah struktur itu berevolusi di masa depan tanpa merusak client yang sudah ada.

// Array — akses via index
["apple", "banana", "cherry"][0]  // "apple"

// Object — akses via key
{"first": "apple", "second": "banana"}["first"]  // "apple"

Kapan Pakai Array

Gunakan array ketika:

• Urutan itu penting — misalnya daftar langkah instruksi, riwayat transaksi terurut waktu, atau ranking leaderboard.
• Item-item bersifat homogen — semua elemen punya bentuk/struktur yang sama, seperti daftar produk atau daftar user.
• Jumlah item bisa berubah-ubah secara dinamis dan kamu perlu operasi seperti append, filter, atau iterasi berurutan.
• Kamu tidak butuh akses cepat berdasarkan identifier unik — kalau akses utama cuma "ambil semua" atau "loop semua", array sudah cukup.

{
  "products": [
    { "id": 1, "name": "Kaos Polos" },
    { "id": 2, "name": "Celana Jeans" }
  ]
}

Kapan Pakai Object

Gunakan object ketika:

• Kamu butuh akses cepat (O(1) lookup) berdasarkan key unik — misalnya mengambil data user berdasarkan ID tanpa perlu loop mencari.
• Setiap item punya identitas yang jelas dan unik yang cocok dijadikan key, seperti kode negara, slug, atau ID.
• Struktur mewakili "record" dengan field yang punya makna berbeda-beda (bukan koleksi item sejenis) — misalnya data satu user dengan field name, email, age.
• Urutan tidak relevan secara semantik — kalau urutan data tidak mempengaruhi arti data itu, object lebih tepat secara konseptual.

{
  "usersById": {
    "u001": { "name": "Sarah Amelia" },
    "u002": { "name": "Budi Santoso" }
  }
}

Dibandingkan representasi array untuk kasus yang sama:

{
  "users": [
    { "id": "u001", "name": "Sarah Amelia" },
    { "id": "u002", "name": "Budi Santoso" }
  ]
}

Kedua bentuk ini valid, tapi dengan trade-off berbeda: bentuk object memudahkan lookup langsung (usersById["u001"]), sementara bentuk array lebih mudah untuk iterasi berurutan, sorting, atau ditampilkan sebagai list/tabel di UI. Tim frontend biasanya lebih menyukai bentuk array karena lebih mudah di-loop dengan map()/filter(), sementara tim yang membangun cache atau state management di sisi client kadang lebih suka bentuk object supaya update satu item tidak perlu mencari index-nya lebih dulu.

Kesalahan Umum: Memakai Object Padahal Harusnya Array

Kesalahan desain yang cukup sering terjadi adalah memakai object dengan key berupa angka berurutan, padahal maksudnya adalah list:

// Kurang tepat
{
  "0": "apple",
  "1": "banana",
  "2": "cherry"
}

// Lebih tepat
["apple", "banana", "cherry"]

Pola pertama sering muncul secara tidak sengaja akibat serialisasi otomatis dari bahasa pemrograman tertentu (misalnya PHP associative array yang keynya kebetulan angka berurutan). Ini bikin bingung konsumen API — mereka harus menebak apakah itu "object beneran" atau "array yang salah bentuk". Kalau kamu menemukan pola ini di API yang sedang kamu desain, hampir selalu lebih baik memperbaikinya menjadi array asli sebelum dipublikasikan, karena mengubahnya belakangan setelah banyak client bergantung padanya jauh lebih menyakitkan.

Kesalahan Umum: Memakai Array Padahal Harusnya Object

Sebaliknya, kadang orang memakai array untuk data yang sebenarnya lebih cocok jadi object, misalnya representasi field dengan nama tetap:

// Kurang tepat — urutan implisit yang mudah salah
["Sarah Amelia", "sarah@example.com", 29]

// Lebih tepat — jelas field mana yang mana
{ "name": "Sarah Amelia", "email": "sarah@example.com", "age": 29 }

Representasi array untuk record dengan field bermakna berbeda sangat rawan bug — kalau urutan field berubah di versi API berikutnya (misalnya ditambah satu field di tengah), semua client yang mengandalkan index posisi akan rusak diam-diam tanpa error yang jelas.

Kasus Ambigu: Kapan Boleh Keduanya?

Beberapa API menyediakan dua representasi untuk kebutuhan berbeda, misalnya endpoint utama mengembalikan array untuk ditampilkan berurutan, sementara endpoint atau field terpisah menyediakan bentuk object untuk lookup cepat. Ini valid selama didokumentasikan dengan jelas dan tidak membingungkan konsumen API tentang representasi mana yang jadi "sumber kebenaran".

Pertimbangan Performa

Dari sisi performa runtime, lookup di object (biasanya diimplementasikan sebagai hash map di kebanyakan bahasa pemrograman) jauh lebih cepat — O(1) rata-rata — dibanding mencari item tertentu di array yang butuh O(n) karena harus di-loop satu-satu (kecuali di-sort dan pakai binary search). Kalau kamu tahu use case utamanya adalah "cari item spesifik berdasarkan ID dengan cepat", dan datasetnya besar, representasi object bisa memberi keuntungan performa nyata di sisi client setelah data di-parse.

Bagaimana Bahasa Pemrograman Memetakan Ini?

Perlu diingat, "array" dan "object" di JSON adalah konsep abstrak yang dipetakan berbeda-beda tergantung bahasa pemrograman yang men-decode-nya. Di JavaScript, array JSON jadi Array dan object JSON jadi Object biasa — sangat natural karena JSON memang meniru sintaks JS. Di Python, array jadi list dan object jadi dict. Di Java atau Go yang statically typed, biasanya kamu perlu mendefinisikan struct/class eksplisit terlebih dahulu supaya proses decode tahu field apa saja yang diharapkan — array JSON dipetakan ke List/slice, dan object ke instance class. Perbedaan ini kadang membuat desain "array vs object" yang terlihat sepele di JSON ternyata berdampak signifikan ke kompleksitas kode consumer di bahasa yang lebih strict soal tipe.

Rangkuman Cepat

• Urutan penting, item homogen, butuh iterasi → array
• Butuh lookup cepat by key, item punya identitas unik → object
• Record dengan field bermakna berbeda-beda → object, bukan array posisional
• List sederhana tanpa makna khusus di posisinya → array, bukan object dengan key angka

🔧 Cek Struktur JSON Kamu di JSONYAMify

// Array — access via index
["apple", "banana", "cherry"][0]  // "apple"

// Object — access via key
{"first": "apple", "second": "banana"}["first"]  // "apple"

{
  "products": [
    { "id": 1, "name": "Plain T-Shirt" },
    { "id": 2, "name": "Jeans" }
  ]
}

{
  "usersById": {
    "u001": { "name": "Sarah Amelia" },
    "u002": { "name": "Budi Santoso" }
  }
}

{
  "users": [
    { "id": "u001", "name": "Sarah Amelia" },
    { "id": "u002", "name": "Budi Santoso" }
  ]
}

// Not ideal
{
  "0": "apple",
  "1": "banana",
  "2": "cherry"
}

// Better
["apple", "banana", "cherry"]

// Not ideal — implicit order that's easy to get wrong
["Sarah Amelia", "sarah@example.com", 29]

// Better — clear which field is which
{ "name": "Sarah Amelia", "email": "sarah@example.com", "age": 29 }