Kamu pernah nggak lagi asyik nge-build API pakai JSON, eh tiba-tiba ada request fitur upload foto profil atau dokumen PDF? Di sini biasanya drama dimulai. JSON itu isinya teks (string), sedangkan file itu data biner. Mereka nggak “ngobrol” di bahasa yang sama.
Pertanyaannya: Gimana cara handle-nya supaya API kamu tetap rapi, cepat, dan nggak bikin server jebol? Apakah harus dipisah atau digabung sama data JSON lainnya?
Mari kita bedah dua solusi yang paling sering dipakai oleh para senior developer.
Solusi 1: Membungkus File ke dalam JSON (Base64 Encoding)
Ini adalah cara yang paling simpel dan sering jadi “pertolongan pertama.” Karena JSON nggak bisa nerima file mentah, kita ubah file tersebut menjadi string panjang menggunakan format Base64.
Gimana Cara Kerjanya?
Front-end akan melakukan encode pada file kamu, lalu mengirimkannya sebagai salah satu field di dalam JSON. Contohnya seperti ini:
{
"name": "Budi Santoso",
"email": "budi@example.com",
"profile_image": "data:image/png;base64,iVBORw0KGgoAAAANSUh..."
}
Kelebihan & Kekurangan
- Pro: Sangat simpel. Kamu cuma butuh satu endpoint API untuk kirim data sekaligus file-nya.
- Cons: Payload jadi bengkak! Base64 bikin ukuran file naik sekitar 33%. Kalau kamu upload file 10MB, data yang dikirim ke server jadi sekitar 13MB+.
Tips Expert: Gunakan solusi ini hanya untuk file kecil di bawah 1MB (seperti foto profil kecil atau file tanda tangan). Kalau buat upload video, cara ini bakal bikin servermu nangis.
Solusi 2: Strategi Presigned URL (The “Pro” Way)
Kalau kamu ingin aplikasi yang scalable dan ringan, jangan biarkan server API kamu sibuk ngurusin traffic upload file. Serahkan tugas berat itu ke ahlinya: Object Storage (seperti AWS S3, Google Cloud Storage, atau Cloudflare R2).
Strategi ini sering disebut dengan Sign URL atau Presigned URL.
Workflow-nya Keren Banget:
- Minta Izin: Klien minta URL upload ke API kamu.
- Kirim Tiket: API kamu minta “URL sekali pakai” ke Object Storage, lalu kasih URL itu ke klien.
- Upload Langsung: Klien upload file langsung ke Object Storage pakai URL tadi. API kamu nggak dilewati file sama sekali!
- Lapor: Setelah upload beres, klien baru lapor ke API kamu dengan mengirimkan ID file-nya.
Kenapa Ini Jauh Lebih Bagus?
Dengan cara ini, servermu cuma sibuk ngurusin data teks yang ringan. Bandwidth server nggak habis buat narik file gede, karena proses upload-nya “bypass” langsung ke storage cloud.
Insight Veteran: Cara Mengatasi “File Sampah”
Banyak yang tanya: “Bang, kalau user udah upload file ke storage tapi ternyata gagal submit data JSON-nya, berarti jadi file sampah dong?”
Nah, ini advanced tip buat kamu: gunakan fitur Auto-Cleanup dan Temporary Path.
- Gunakan Folder Temp: Simpan file hasil upload pertama di folder
/temp. - Konfirmasi Sukses: Begitu data JSON berhasil masuk database, baru pindahkan file dari
/tempke folder/final. - Auto Delete: Setting Object Storage kamu untuk otomatis hapus file di folder
/tempyang usianya sudah lebih dari 24 jam.
Dengan begini, storagemu bakal tetap bersih tanpa perlu kamu hapus manual satu-persatu!
Kesimpulan: Pilih yang Mana?
Nggak ada solusi yang salah, yang ada cuma solusi yang kurang pas dengan kebutuhanmu.
- Pilih Base64 kalau projectmu kecil, file-nya ringan, dan kamu pengen cepat beres.
- Pilih Sign URL + Object Storage kalau kamu sedang membangun sistem yang bakal dipakai banyak orang dan ingin performa server tetap stabil.
Sekarang, coba cek project kamu. Masih pakai cara lama yang bikin server lemot, atau sudah siap beralih ke strategi yang lebih clean?
Gimana menurutmu? Lebih suka pakai cara yang simpel atau yang lebih terstruktur? Tulis pendapatmu di kolom komentar ya!
Suka dengan tips teknis seperti ini?
Jangan lupa Subscribe Newsletter kita buat dapetin update seputar arsitektur API dan tips coding lainnya langsung di emailmu!
