Sebuah permintaan API dapat selesai secara teknis tetapi tetap gagal memenuhi kebutuhan aplikasi. Browser menerima respons, server mengirim status penolakan, lalu kode mencoba membaca isi sebagai JSON. Jika seluruh kegagalan hanya ditangani melalui catch, sebagian kondisi dapat luput. Memahami lapisannya membantu pengembang memberi pesan yang tepat dan menghindari indikator sukses yang tidak sesuai dengan hasil operasi pada layanan penerima.
Fetch mengembalikan promise yang dapat terpenuhi dengan objek Response meskipun status HTTP menunjukkan masalah. Karena itu, respons 404 bukan otomatis sama dengan kegagalan jaringan. Aplikasi perlu memeriksa status dan membaca kontrak endpoint. Jangan menggunakan contoh yang hanya menampilkan hasil response.json tanpa mempertimbangkan apa yang terjadi ketika alamat salah, sesi berakhir, atau server mengembalikan format berbeda dari respons sukses yang diharapkan.
Mulai dari pertanyaan apakah respons diterima
Gangguan koneksi, pemblokiran tertentu, dan pembatalan dapat membuat permintaan tidak memberikan respons yang dapat dipakai kode. Catch membantu menangani penolakan promise, tetapi pesan untuk pengguna tetap memerlukan konteks. Jangan langsung mengatakan internet pengguna mati karena kegagalan bisa berasal dari konfigurasi aplikasi atau kebijakan browser. Simpan informasi teknis secukupnya untuk diagnosis tanpa membocorkan data pribadi atau kredensial pada log yang mudah diakses.
Untuk aplikasi pencarian, permintaan lama mungkin sengaja dibatalkan ketika pengguna mengetik kata baru. Itu bukan keadaan yang perlu selalu ditampilkan sebagai error merah. Bedakan pembatalan yang diharapkan dari gangguan yang perlu tindakan pengguna. Jika tidak dibedakan, antarmuka dapat terus menampilkan pesan gagal padahal pembatalan merupakan bagian normal dari rancangan pencarian yang sedang bekerja sesuai urutan interaksi yang diinginkan oleh pengembang.
Jangan biarkan respons lama menimpa hasil baru
Pengguna dapat mengganti filter sebelum permintaan sebelumnya selesai. Tanpa pengelolaan urutan, respons lama yang lebih lambat dapat muncul setelah respons terbaru. Gunakan pembatalan atau identitas permintaan sesuai kebutuhan untuk memastikan hasil yang ditampilkan masih relevan. Periksa skenario ini dengan koneksi lambat, bukan hanya pada localhost yang cepat sehingga kondisi balapan jarang terlihat saat komponen pertama kali dibuat dan dicoba oleh pengembang.
Periksa status HTTP sebelum menganggap sukses
Response.ok menunjukkan apakah status berada pada rentang sukses HTTP. Namun, makna operasional tetap mengikuti kontrak API. Sebuah endpoint dapat mengembalikan data validasi dengan status penolakan, sementara endpoint lain mengembalikan status sukses disertai informasi bahwa pekerjaan masih mengantre. Tentukan cabang penanganan berdasarkan dokumentasi layanan, bukan hanya satu pola generik yang disalin dari contoh permintaan ke endpoint berbeda pada proyek lain.
Pada error HTTP, jangan selalu mencoba mengulang otomatis. Pengulangan permintaan yang mengubah data dapat menghasilkan tindakan ganda jika server sudah memproses sebagian operasi. Untuk operasi penting, pelajari dukungan identitas permintaan atau mekanisme idempotensi penyedia. Jika belum ada, tampilkan status secara hati-hati dan sediakan langkah pemulihan yang tidak mendorong pengguna menekan tombol berkali-kali tanpa mengetahui apa yang terjadi pada sisi layanan.
Isi respons mempunyai kegagalan tersendiri
JSON yang diharapkan mungkin digantikan halaman HTML dari proxy, halaman login, atau pesan gangguan. Pemanggilan json dapat gagal ketika isi tidak sesuai format. Periksa kontrak dan header yang relevan, tetapi tetap tangani kegagalan parsing karena label format juga bisa tidak sesuai isi. Jangan mencetak seluruh body pada layar pengguna hanya untuk mempermudah diagnosis jika respons mengandung rincian internal atau informasi sensitif.
Setelah berhasil membaca JSON, periksa bentuk datanya. Objek yang sah secara sintaks belum tentu mempunyai field yang diperlukan komponen. Array kosong, nilai null, dan perubahan tipe dapat menyebabkan kegagalan berikutnya. Pada batas API, validasi runtime membantu membedakan data yang dapat digunakan dari data yang perlu ditolak atau diperlakukan sebagai keadaan kosong. Type assertion tidak melakukan pemeriksaan tersebut ketika program benar-benar dijalankan.
Body biasanya tidak dibaca berulang
Body respons berbasis stream tidak dapat diperlakukan seperti variabel teks yang bebas dibaca berkali-kali. Jika perlu membaca dua salinan, pelajari penggunaan clone sebelum body dikonsumsi. Jangan menambahkan pembacaan kedua hanya untuk logging tanpa memahami dampaknya. Untuk banyak aplikasi, satu proses pembacaan dan pemisahan hasil sesudahnya sudah cukup sehingga alurnya lebih sederhana dan kesalahan penggunaan stream lebih mudah dihindari saat pemeliharaan.
Rancang pesan berdasarkan tindakan berikutnya
Pisahkan keadaan data kosong, akses ditolak, format tidak didukung, dan layanan terganggu. Pengguna tidak membutuhkan semua kode internal, tetapi perlu mengetahui apakah bisa memperbaiki input, masuk kembali, atau mencoba nanti. Pastikan indikator memuat berhenti pada seluruh jalur. Hindari menghapus data lama yang masih berguna tanpa alasan ketika pembaruan gagal, terutama jika pengguna sedang membaca hasil yang sudah ditampilkan sebelum permintaan baru dimulai.
Uji menggunakan respons yang dikendalikan: status sukses, error HTTP, JSON rusak, data kosong, serta pembatalan. Catat hasil yang diharapkan sebelum menjalankan pengujian. Cara ini membantu menemukan cabang yang terlewat dan memastikan perubahan penanganan error tidak sekadar memindahkan masalah dari console ke notifikasi yang membingungkan. Respons jaringan hanyalah awal; aplikasi bertanggung jawab menerjemahkannya menjadi pengalaman yang dapat dipahami oleh pengguna pada kondisi sebenarnya.
Log seperlunya
Catat jenis kegagalan, endpoint yang sudah disamarkan bila perlu, dan identitas permintaan yang aman. Jangan menyimpan token, cookie, atau seluruh respons pelanggan tanpa dasar operasional. Log yang ringkas tetapi terstruktur membantu menghubungkan laporan pengguna dengan kejadian server. Tentukan pula siapa yang boleh mengakses catatan dan kapan catatan dihapus.
