Deserialisasi: apa itu, proses pemulihan data

Apa itu deserialisasi?

Deserialisasi — proses mengubah aliran byte atau teks terstruktur menjadi objek bahasa pemrograman. Dalam pengembangan mobile, proses ini terjadi setiap kali aplikasi menerima respons dari server: string JSON berubah menjadi instance dari kelas User, Order atau Product. Stabilitas layar yang menampilkan data kepada pengguna secara langsung tergantung pada kebenaran deserialisasi.

Perbedaan dari serialisasi

Serialisasi dan deserialisasi adalah proses yang saling berlawanan, jarang simetris dalam praktiknya. Serialisasi mengubah objek menjadi string untuk dikirim ke server, deserialisasi memulihkan objek dari string yang diterima. Server dapat mengirim bidang yang tidak ada dalam model klien, menggunakan format tanggal yang berbeda, atau mengembalikan null alih-alih angka. Menurut Square Engineering (2025), asimetri format adalah penyebab 23% kesalahan lapisan jaringan di aplikasi Android. Untuk mengurangi risiko, digunakan versioning skema dan spesifikasi kontrak yang ketat melalui OpenAPI.

Format data untuk deserialisasi

JSON tetap menjadi format paling populer untuk API mobile karena keterbacaannya dan dukungan bawaan. Protobuf dari Google digunakan dalam sistem high-load — 3-6 kali lebih ringkas dari JSON dan lebih cepat diurai, tetapi memerlukan pembuatan kode dari file .proto dan tidak terbaca tanpa alat. XML lebih jarang ditemui di aplikasi mobile modern, namun digunakan dalam layanan SOAP sistem perusahaan dan file konfigurasi Android. MessagePack — format biner mirip JSON dalam struktur tetapi lebih ringkas, populer di sistem waktu nyata.

Bagaimana cara kerja deserialisasi

Proses deserialisasi melalui tiga tahap. Pertama tokenisasi memecah teks mentah menjadi leksem: kunci, string, angka dan pemisah. Kemudian analisis sintaksis memeriksa kebenaran struktur — apakah kurung ditutup, apakah jenis tanda kutip benar, apakah format sesuai spesifikasi RFC 8259. Tahap akhir adalah pemetaan ke model objek aplikasi, di mana setiap kunci JSON diberikan properti kelas dengan mempertimbangkan strategi penamaan.

Reflection vs Code generation

Dalam pengembangan mobile, dua pendekatan pemetaan telah terbentuk. Reflection (Gson, JSONSerialization) menganalisis struktur kelas saat runtime melalui Java Reflection API atau Objective-C runtime — fleksibel dan tidak memerlukan konfigurasi tambahan, tetapi lebih lambat dan menggunakan lebih banyak memori. Code generation (Moshi codegen, kotlinx.serialization, Codable) menghasilkan kode pada tahap kompilasi: lebih cepat, lebih aman dari segi tipe, dan tidak mengekspos struktur internal melalui reflection. JetBrains dan Square merekomendasikan code generation untuk build produksi — peningkatan kinerja mencapai 2-4 kali dalam benchmark Google.

struct User: Codable {
    let id: Int
    let name: String
    let email: String
    let createdAt: Date
}

let json = """
{
    "id": 42,
    "name": "Alice",
    "email": "alice@example.com",
    "created_at": "2026-06-01T12:00:00Z"
}
"""
let decoder = JSONDecoder()
decoder.keyDecodingStrategy = .convertFromSnakeCase
let user = try decoder.decode(User.self, from: data)

Contoh deserialisasi JSON ke model User di Swift. Strategi convertFromSnakeCase secara otomatis mengubah kunci API snake_case menjadi properti model camelCase — praktik standar dalam proyek iOS. Parameter data adalah byte mentah dari respons server, diperoleh melalui URLSession. Penanganan kesalahan melalui try memungkinkan menangkap JSON yang tidak valid tanpa menyebabkan aplikasi crash.

Peran strategi decoding

JSONDecoder mendukung empat strategi kunci: useDefaultKeys (pencocokan tepat), convertFromSnakeCase (snake_case → camelCase), custom (closure) dan convertFromKebabCase (kebab-case → camelCase). Untuk tanggal tersedia .iso8601, .secondsSince1970, .millisecondsSince1970 dan dateFormatter kustom. Memilih strategi yang tepat adalah langkah pertama menuju deserialisasi yang stabil, mencegah sebagian besar kesalahan ketidakcocokan format.

Deserialisasi di iOS

JSONDecoder — mekanisme deserialisasi standar di iOS SDK yang bekerja dengan protokol Codable. JSONDecoder secara otomatis mengurai JSON menjadi instance struct atau class, mendukung objek bersarang, array dan tipe primitif. Untuk logika khusus digunakan metode init(from: Decoder) — metode ini memungkinkan menangani format tidak standar, bidang yang dilewatkan di versi API lama, atau menggabungkan beberapa kunci JSON menjadi satu properti.

struct Order: Decodable {
    let orderId: String
    let amount: Double
    let status: OrderStatus

    enum OrderStatus: String, Decodable {
        case pending, confirmed, shipped, cancelled
    }
}

let decoder = JSONDecoder()
decoder.dateDecodingStrategy = .iso8601
let order = try decoder.decode(Order.self, from: jsonData)

DateDecodingStrategy menentukan bagaimana JSONDecoder menginterpretasikan string dengan tanggal. Paling sering digunakan .iso8601 — format standar REST API. Enum bersarang OrderStatus secara otomatis didekode dari nilai string JSON. Ini menghindari angka ajaib dan membuat kode menjadi self-documenting — status pesanan selalu memiliki kumpulan nilai yang ditentukan secara ketat.

Property Wrappers di Codable

Mulai Swift 4.2, Codable mendukung property wrappers untuk deserialisasi khusus properti individu. @DefaultValue — wrapper populer yang menetapkan nilai default jika bidang tidak ada di JSON. @LosslessString mengubah string menjadi angka dan sebaliknya. Ini sangat berguna ketika server mengirim id sebagai string „123” dan model mengharapkan Int. Property wrappers mengurangi kode boilerplate di init(from:) dan membuat model lebih bersih.

Deserialisasi di Android

Di Android, pemilihan pustaka deserialisasi tergantung pada bahasa dan kebutuhan proyek. Gson dari Google — opsi paling umum yang bekerja melalui reflection, tetapi memiliki masalah kinerja pada hierarki yang kompleks. Moshi dari Square mendukung baik reflection maupun code generation, menggunakan lebih sedikit memori dan memproses respons besar lebih cepat. kotlinx.serialization dari JetBrains — solusi native Kotlin dengan integrasi kompiler yang tidak menggunakan reflection sama sekali.

@Serializable
data class User(
    @SerialName("user_id")
    val userId: Int,
    val name: String,
    val email: String,
    @SerialName("created_at")
    val createdAt: String
)

val json = Json { ignoreUnknownKeys = true }
val user = json.decodeFromString<User>(response)

@Serializable — anotasi kompiler Kotlin yang mengaktifkan pembuatan kode untuk kelas. Parameter ignoreUnknownKeys mencegah crash jika server mengirim bidang yang tidak ada dalam model. Untuk memetakan kunci snake_case digunakan @SerialName — setara dengan convertFromSnakeCase dari iOS. Menurut JetBrains (2026), pustaka ini mendukung multi-platform: kelas Serializable yang sama bekerja di Android, iOS (KMP) dan server Kotlin.

Perbandingan Gson, Moshi dan kotlinx.serialization

Pilihan di antara pustaka bermuara pada kompromi kecepatan-fleksibilitas. Gson bagus untuk prototipe dan proyek Java — tidak memerlukan anotasi dan bekerja „siap pakai”. Moshi menempati posisi tengah: codegen melalui @JsonClass(generateAdapter = true) memberikan kecepatan mendekati kotlinx.serialization, dan mode reflection memberikan fleksibilitas Gson. kotlinx.serialization — opsi tercepat untuk proyek Kotlin murni, tetapi memerlukan Kotlin 1.4+ dan plugin Kotlin Serialization di Gradle.

Kesalahan umum dan pencegahannya

Type mismatch — situasi ketika JSON berisi nilai dari satu tipe dan model mengharapkan tipe lain. Server mengirim string „42” alih-alih angka atau angka 1 alih-alih boolean true. Di iOS, JSONDecoder secara default akan melempar DecodingError.typeMismatch, di Android Gson akan mencoba mengonversi, sedangkan Moshi dan kotlinx.serialization memerlukan adaptor eksplisit. Solusi — gunakan strategi lenient atau deserializer kustom untuk bidang tertentu.

Bidang hilang dan nullable

Ketika server tidak menyertakan bidang opsional, kode akan crash dengan kesalahan. Optional di Swift dan tipe nullable di Kotlin memecahkan masalah: jika bidang bernilai null atau tidak ada di JSON, properti mendapat nilai nil/null dan aplikasi terus berjalan. Untuk bidang wajib, ada baiknya memeriksa keberadaannya di tingkat klien API sebelum deserialisasi. Moshi dan kotlinx.serialization secara default memerlukan semua bidang — penandaan nullable dan nilai default menghapus batasan ini.

Ketidakcocokan versi API

Perubahan struktur JSON di server — sumber umum crash di produksi. Praktik standar adalah versioning skema melalui bidang version di objek root dan dukungan untuk 2-3 versi sebelumnya di sisi klien. kotlinx.serialization memungkinkan mendeklarasikan beberapa model untuk versi berbeda dan memilih yang sesuai berdasarkan bidang version setelah parsing awal ke JsonElement. Perlindungan tambahan — ignoreUnknownKeys untuk bidang baru dan nilai default untuk bidang yang mungkin dihapus.

Logging kesalahan deserialisasi — praktik wajib di produksi. Bungkus decode dalam do/catch, log JSON mentah dan tipe model yang diharapkan di Crashlytics atau Sentry. Ini memungkinkan dengan cepat menentukan bidang API mana yang rusak dan pada versi aplikasi mana. Tanpa logging, kesalahan deserialisasi tampak seperti crash misterius tanpa konteks.