Petunjuk dan konteks
Sebuah API online harus memindahkan jalur sumber dayanya secara permanen dari /v1/orders ke /v2/orders. Penelepon mencakup formulir peramban (browser), klien seluler, SDK pihak ketiga, dan pekerja asinkron; permintaan dapat berupa POST dengan body JSON berukuran besar dan kunci idempotensi (idempotency key). Rancang kode status, perilaku klien, observabilitas, dan jalur rollback untuk migrasi tersebut.
Pertanyaan ini menguji apakah Anda dapat menerapkan semantik pengalihan secara tepat dan menghindari efek samping (side effects) duplikat selama pemindahan API. RFC 9110 mendefinisikan 308 Permanent Redirect; MDN menjelaskan bahwa klien tidak boleh mengubah metode asli atau body permintaan saat mengirim ulang permintaan ke lokasi baru. 301 bersifat permanen, tetapi klien terdahulu (historis) memiliki perbedaan kompatibilitas untuk permintaan non-GET dan mungkin mengubah metodenya.
Apa yang sedang diuji oleh pewawancara
Pewawancara ingin Anda memisahkan pemindahan permanen dari pemindahan sementara, lalu menanyakan apakah pemeliharaan metode dan body diperlukan. Jawaban yang kuat membandingkan 301, 302, 307, dan 308, menjelaskan mengapa POST yang memiliki efek samping tidak dapat bergantung pada tebakan klien mengenai cara mencoba ulang (retry), serta mencakup idempotency key, autentikasi, batas waktu (timeout), dan rollback.
Mereka juga mengharapkan Anda mempertimbangkan batas kepercayaan dari header Location, kredensial lintas-asal (cross-origin), propagasi cache, batas pengalihan SDK, dan klien yang tidak mendukung 308. Hanya melafalkan "308 adalah 301 ditambah pemeliharaan POST" tanpa rencana pengujian migrasi adalah jawaban yang tidak lengkap.
Klarifikasi yang perlu ditanyakan terlebih dahulu
Permanensi dan cakupan
Konfirmasikan bahwa URL baru stabil dan apakah pemindahan mencakup satu sumber daya, awalan API, atau asal (origin) yang berbeda. Jika target masih dapat berubah, gunakan 307 untuk menyatakan pemindahan sementara alih-alih mengajarkan semantik cache permanen secara prematur kepada klien dan perantara.
Kemampuan klien dan efek samping
Buat daftar peramban, versi seluler, SDK, konsumen antrean, dan mitra. Tanyakan apakah POST membuat pesanan, menagih uang, atau memancarkan pesan, dan apakah penelepon mengirimkan idempotency key. Tanpa bukti bahwa pemutaran ulang (replay) aman, pengalihan bukanlah instruksi percobaan ulang tanpa syarat.
Kredensial, cache, dan rollback
Konfirmasikan cakupan autentikasi, CORS, proksi, dan perilaku CDN untuk kedua host. Tanyakan apakah endpoint lama dapat terus melayani dan apakah rollback berarti menghapus pengalihan, mengalihkan perutean, atau memulihkan handler lama.
Jawaban 30 detik
"Pertama-tama saya akan mengonfirmasi apakah pemindahan bersifat permanen dan menginventarisasi setiap klien. Untuk pemindahan permanen yang harus mempertahankan metode dan body POST, saya akan menggunakan 308; pemindahan sementara menggunakan 307. 301 bukanlah kontrak yang ketat untuk mempertahankan semantik non-GET di seluruh klien historis. Awalnya saya akan mem-proxy endpoint lama ke handler baru, menggunakan kembali satu idempotency key untuk setiap efek samping, serta membatasi host Location dan penerusan kredensial. Selama uji coba canary, saya akan melacak tingkat tindak lanjut 3xx, pembuatan duplikat, 4xx/5xx, ukuran body, dan versi SDK. Jika sinyal memburuk, saya akan berhenti mengirim 308 dan menjaga endpoint lama tetap mampu melayani lalu lintas."
Pembahasan mendalam langkah demi langkah
Langkah 1: Pilih kode status secara tepat
308 berarti pemindahan permanen dan mempertahankan metode serta body permintaan; 307 bersifat sementara dan juga mempertahankan keduanya. 301 bersifat permanen, tetapi klien historis tidak semuanya mempertahankan metode seperti POST, sehingga ini bukan kontrak migrasi POST yang ketat. 302 juga tidak boleh membawa jaminan tersebut.
Langkah 2: Perlakukan replay sebagai kendala utama
Karena 308 dapat menyebabkan klien mengirimkan seluruh isi body lagi, kedua endpoint harus mengenali perintah bisnis yang sama dengan idempotency key yang sama. Sebelum mengeksekusi efek samping, server memvalidasi kunci terhadap digest permintaan; kunci yang sama dengan parameter berbeda menjadi konflik alih-alih pesanan kedua. Klien tetap mengikuti anggaran percobaan ulangnya setelah timeout dan tidak boleh mengikuti 308 selamanya.
Langkah 3: Rilis secara bertahap dan amati
Pastikan alamat baru berfungsi secara langsung sebelum merutekan alamat lama melalui proksi yang dapat diobservasi atau respons 308. Lakukan rilis canary berdasarkan versi SDK, origin sumber, dan metode. Catat panjang rantai pengalihan, kegagalan tindak lanjut pengalihan, efek samping duplikat, latensi target, kegagalan autentikasi, dan ukuran body. Untuk klien yang tidak mendukung 308, pertahankan proksi sisi server berumur pendek daripada beralih secara diam-diam ke 301 dan mengasumsikan perilaku yang setara.
Langkah 4: Tangani keamanan, caching, dan rollback
Location hanya boleh mengarah ke target yang masuk dalam daftar izin (allow-list). Evaluasi ulang cookie, Authorization, dan CORS sebelum lompatan lintas-asal sehingga kredensial tidak sampai ke host yang tidak tepercaya. Buat jendela cache CDN dan klien eksplisit, dimulai dengan durasi pendek selama validasi dan diperpanjang secara bertahap. Saat rollback, hentikan penerbitan pengalihan baru dan biarkan endpoint lama menerima idempotency key yang sama; hasil yang sudah ditulis di endpoint baru tidak dapat 'dibatalkan' hanya dengan mengalihkan rute kembali.
Contoh jawaban berkualitas tinggi
Saya akan memperlakukan ini sebagai pertanyaan protokol dan migrasi, bukan latihan memilih angka. Untuk pemindahan permanen di mana metode dan body POST harus dipertahankan, saya memilih 308; untuk pengalihan lalu lintas sementara, saya memilih 307. 301 sesuai untuk banyak pemindahan URL halaman web, tetapi tidak memberikan jaminan pemeliharaan metode ketat yang saya perlukan untuk API non-GET.
Sebelum peluncuran, kedua URL mendukung autentikasi, validasi permintaan, dan kontrak idempotency-key yang sama. Endpoint lama awalnya mem-proxy ke handler baru dengan log lengkap, dan kunci yang sama ditambah digest permintaan hanya dapat menghasilkan satu efek samping. Kemudian saya melakukan canary 308 berdasarkan versi klien, membatasi host target, memeriksa ulang kredensial lintas-asal, dan memverifikasi perilaku CDN, SDK, serta konsumen antrean.
Saya memantau tingkat tindak lanjut pengalihan, panjang rantai, pembuatan duplikat, kesalahan target, kegagalan autentikasi, dan ukuran body. Jika klien lama tidak memahami 308, saya mempertahankan proksi endpoint lama daripada menurunkannya secara diam-diam ke 301. Selama insiden, saya menghentikan 308, mempertahankan endpoint lama dan catatan idempotensi, memulihkan perutean, serta merekonsiliasi hasil bisnis yang telah selesai berdasarkan ID permintaan.
Kesalahan umum
- Mengembalikan 301 untuk setiap pemindahan → Klien historis dapat mengubah POST ke metode lain atau menghapus body → Gunakan 308 untuk pemindahan API permanen yang memerlukan pemeliharaan metode, lalu verifikasi klien.
- Mengeksekusi efek samping lagi setelah melihat 308 → Pengalihan, timeout, dan percobaan ulang klien dapat melipatgandakan permintaan pembuatan → Gunakan idempotency key, digest permintaan, dan anggaran percobaan ulang yang terikat batas.
- Memperlakukan 307 sebagai permanen → Kondisi sementara dapat bertahan lama di cache atau konfigurasi SDK, membuat rollback lebih sulit → Gunakan 307 untuk pengalihan sementara dan tentukan 308 hanya setelah stabilisasi.
- Mengabaikan risiko Location lintas-asal → Cookie atau Authorization dapat mencapai target yang tidak tepercaya → Validasi daftar izin, kebijakan kredensial, dan CORS secara bersamaan.
- Hanya melihat jumlah 3xx → Kegagalan tindak lanjut SDK lama dan penulisan duplikat tetap tidak terlihat → Gabungkan tingkat tindak lanjut, kesalahan, dan hasil efek samping berdasarkan versi klien.
Pertanyaan lanjutan
Pertanyaan lanjutan 1: Mengapa tidak mengembalikan 200 dari URL lama dan menyebutkan URL baru di dalam body?
Hal itu tidak memungkinkan klien umum, cache, atau SDK bermigrasi secara otomatis, dan tidak menyatakan bahwa sumber daya telah berpindah secara permanen. Proksi sisi server dapat dipertahankan selama masa transisi, tetapi kontrak migrasi tetap memerlukan status eksplisit dan header Location sambil mencatat apakah pemanggil benar-benar telah beralih.
Pertanyaan lanjutan 2: Bisakah 308 meneruskan Authorization tanpa perubahan ke host baru?
Tidak secara default. Pertama-tama pastikan bahwa kedua host berbagi batas tepercaya; jika tidak, minta klien mendapatkan atau secara eksplisit mengirimkan kredensial untuk host target. Server harus menolak nilai Location yang dikendalikan pengguna untuk menghindari open redirect dan kebocoran kredensial.
Pertanyaan lanjutan 3: Bagaimana jika klien lama tidak mendukung 308 sama sekali?
Pertahankan proksi sisi server untuk endpoint lama atau kembalikan respons kompatibilitas berdasarkan kemampuan klien yang diketahui hingga versi lama dinonaktifkan. Proksi harus menggunakan kembali idempotency key permintaan dan memiliki tanggal penghentian (retirement); Anda tidak dapat mengklaim setiap klien akan memperlakukan 308 seperti 301 tanpa bukti.
Pertanyaan lanjutan 4: Apakah rollback hanya sekadar mengubah 308 kembali ke 200?
Rekonsiliasi juga pesanan, peristiwa, dan catatan audit yang telah ditulis oleh endpoint baru. Hentikan pengalihan baru dan pulihkan titik masuk lama, lalu buat kedua jalur membaca sumber kebenaran (source of truth) yang sama agar operasi tulis tidak terpecah atau terduplikasi. Verifikasi efek samping yang telah selesai berdasarkan ID permintaan dan idempotency key setelah perutean dipulihkan.