Perintah dan cakupan
Versi API publik dan resource web dihapus secara permanen. Tim ingin klien berhenti mencoba ulang sambil tetap mempertahankan jalur migrasi dan bukti audit. Bandingkan 410, 404, 301/308, dan 403, lalu rancang respons, caching, jendela penonaktifan, dan pemantauan.
Ini adalah pertanyaan tentang semantik HTTP dan siklus hidup produk. Versi dan tanggal penghentian adalah asumsi, bukan klaim pasar.
Hal yang diuji oleh pewawancara
- Apakah Anda membedakan antara "saat ini tidak tersedia" dan "diketahui dihapus secara permanen".
- Apakah Anda memahami dampak 410 pada caching dan klien.
- Apakah migrasi, otorisasi, privasi, dan audit memiliki satu model siklus hidup.
- Apakah Anda menghindari penggunaan kode status untuk menyembunyikan pemadaman yang tidak diketahui atau bug perutean.
Pertanyaan klarifikasi yang perlu diajukan
- Apakah resource dihapus secara permanen, offline sementara, atau dipindahkan ke URI yang stabil?
- Apakah cache, indeks pencarian, percobaan ulang SDK, atau klien offline terlibat?
- Apakah aturan retensi, kepatuhan, atau audit membatasi penghapusan?
- Bisakah klien lama memahami 410 dan informasi migrasi di dalam badan kesalahan?
- Haruskah pengguna yang tidak terotorisasi melihat 404 untuk menyembunyikan keberadaan resource?
Jawaban 30 detik
"410 berarti server mengetahui target pernah ada tetapi telah dihapus secara permanen; 404 hanya menyatakan tidak ada representasi saat ini yang tersedia. Gunakan 301 atau 308 ketika pengganti yang stabil ada, dan 403 atau 404 berbasis keamanan untuk otorisasi. Umumkan penghentian melalui dokumentasi, SDK, dan jendela migrasi, lalu kembalikan 410 dengan kode stabil dan tautan dokumentasi menggunakan kontrol cache yang cermat. Klien harus menghentikan percobaan ulang yang sia-sia. Penghapusan tetap dapat diaudit, dan saya mengukur lalu lintas penghentian, perilaku cache, serta keberhasilan migrasi."
Desain langkah demi langkah
1. Bangun tabel keputusan status
Gunakan 410 untuk resource yang dihapus secara permanen yang tidak akan disajikan lagi. Gunakan 404 ketika keberadaan atau ketersediaan di masa mendatang tidak diketahui, dan pengalihan ketika resource memiliki URI baru yang jelas. Apakah kegagalan otorisasi berupa 403 atau 404 yang disamarkan bergantung pada model ancaman dan kebijakan pengungkapan.
2. Rancang respons 410
Sertakan kode kesalahan yang stabil, ID permintaan, dokumentasi penghentian, dan petunjuk pengganti opsional. Jangan mengekspos alasan penghapusan yang sensitif atau status basis data. API dapat menggunakan badan kesalahan terstruktur; halaman web dapat memberikan penjelasan migrasi yang mudah diakses. Keduanya harus mempertahankan semantik 410 yang dapat dibaca mesin.
HTTP/1.1 410 Gone
Cache-Control: max-age=3600
Content-Type: application/problem+json
Link: <https://api.example/migrations/v1>; rel="deprecation"3. Tangani caching dan klien
410 umumnya dapat di-cache secara heuristik kecuali definisi metode atau kontrol cache eksplisit menyatakan sebaliknya. Evaluasi risiko pencabutan palsu, perilaku CDN, dan cache klien lokal sebelum memilih masa aktif. Jika keputusan dapat berubah, mulailah dengan waktu singkat dan perpanjang secara bertahap. Klien yang melihat 410 harus menghentikan percobaan ulang yang tidak berguna dan beralih ke logika migrasi atau pemberitahuan pengguna.
4. Rencanakan jendela penghentian
Publikasikan tanggal penghentian (deprecation) dalam dokumentasi, SDK, dan header respons, lalu segmentasikan penggunaan berdasarkan pemanggil, versi, dan lalu lintas. Selama jendela tersebut, layani dengan sukses beserta sinyal migrasi; setelah itu kembalikan 410. Operasi tulis berisiko tinggi dapat ditolak terlebih dahulu sementara endpoint migrasi hanya-baca tetap ada. Tentukan titik pemeriksaan rollback sebelum setiap perubahan.
5. Pertahankan bukti penghapusan dan privasi
410 tidak membuktikan penghapusan fisik dari penyimpanan. Catat identitas resource, persetujuan, waktu penghapusan, kebijakan retensi, titik masuk pengganti, dan versi respons. Jangan pernah menyimpan konten sensitif yang dihapus di dalam log. Jika kepatuhan memerlukan penundaan penghapusan, tampilkan 410 sementara retensi dan pembersihan internal berlanjut di bawah kontrol mereka sendiri.
6. Pantau hasil yang diklasifikasikan
Pisahkan 410 berdasarkan resource, klien, versi SDK, hit cache, dan klik migrasi untuk membedakan penghentian nyata dari bug perutean. Bandingkan 404, 403, rantai pengalihan, volume percobaan ulang, dan tiket dukungan. Jika 410 melonjak tanpa diduga, hentikan perpanjangan masa aktif cache dan kembalikan konfigurasi (rollback) sambil menyelidiki.
Contoh jawaban berkualitas tinggi
"Pertama, saya menetapkan status resource. Penghapusan permanen yang diketahui mendapatkan 410; ketiadaan yang tidak diketahui atau sementara mendapatkan 404; pengganti yang jelas mendapatkan 301 atau 308; otorisasi menggunakan 403 atau 404 berbasis keamanan. Saya mengumumkan jendela migrasi melalui dokumen, SDK, dan header, lalu mengembalikan 410 dengan kode stabil, ID permintaan, dan tautan dokumentasi menggunakan caching yang cermat. Klien berhenti mencoba ulang. Penghapusan dan retensi diaudit secara terpisah, sementara metrik mencakup sumber 410, cache, keberhasilan migrasi, dan pemicu rollback."
Kesalahan umum
- Mengembalikan 410 untuk setiap penghapusan → status sementara atau tidak diketahui terlihat permanen → klasifikasikan status resource.
- Mengembalikan 410 meskipun ada pengganti → klien kehilangan migrasi → gunakan 301/308 dan dokumentasi.
- Me-cache 410 selamanya → penghentian yang keliru sulit dibatalkan → tetapkan dan perpanjang TTL berdasarkan risiko.
- Memperlakukan 410 sebagai bukti penghapusan fisik → retensi dan kepatuhan terlewatkan → audit pembersihan secara terpisah.
- Hanya melihat total keseluruhan → kegagalan SDK lama tetap tersembunyi → segmentasikan berdasarkan versi, resource, dan cache.
Pertanyaan lanjutan dan tanggapan
Apa perbedaan esensial antara 410 dan 404?
410 menyatakan bahwa server mengonfirmasi bahwa resource pernah ada dan telah dihapus secara permanen. 404 tidak menyatakan apakah resource tersebut pernah ada atau apakah mungkin muncul nanti. Memilih 410 memberikan jaminan yang lebih kuat tentang perilaku percobaan ulang, caching, dan migrasi.
Bisakah 410 menyertakan tautan pengganti?
Ya, 410 dapat memberikan dokumentasi atau titik masuk migrasi, tetapi tidak boleh berpura-pura bahwa pengganti tersebut adalah resource saat ini. Klien tetap memeriksa ulang otorisasi, versi, dan pemetaan data.
Mengapa pengguna yang tidak terotorisasi mungkin menerima 404?
Jika mengungkapkan bahwa suatu resource ada dapat membocorkan informasi sensitif, server dapat menyembunyikan keberadaannya dengan 404 berdasarkan model ancamannya. Pemanggil yang terotorisasi harus tetap menerima semantik siklus hidup yang konsisten dan dapat diaudit.