Wawancara Backend: Bagaimana Cara Memigrasikan API dari 200 JSON ke 204?

1. Prompt dan Kasus Penggunaan

PATCH /profiles/42 telah berada di lingkungan produksi selama bertahun-tahun. Saat berhasil, endpoint ini mengembalikan 200 OK dengan body tetap: { "success": true }. Aplikasi web, aplikasi seluler, software development kit (SDK) pihak ketiga, dan tugas otomatisasi semuanya memanggilnya. Body tersebut tidak membawa data bisnis apa pun, sehingga tim ingin mengembalikan 204 No Content sebagai gantinya.

Mengubah baris status adalah bagian yang mudah. Klien yang lebih lama mungkin memanggil response.json() untuk setiap respons 2xx, gateway mungkin mengekstrak suatu field dari body, dan dasbor mungkin hanya menghitung 200 sebagai keberhasilan. Migrasi harus memungkinkan klien lama dan baru untuk hidup berdampingan serta menyediakan rollback sisi server yang cepat sebelum masalah kompatibilitas menyebar luas.

2. Hal yang Sedang Diuji oleh Pewawancara

Apakah Anda memperlakukan perubahan status sebagai migrasi kontrak respons (response-contract migration) daripada sekadar pengeditan satu baris kode di server.
Apakah Anda menginventarisasi browser, aplikasi seluler, SDK, proxy, monitor, dan middleware percobaan ulang (retry) sebagai konsumen nyata.
Apakah Anda dapat menjalankan 200 dan 204 secara bersamaan melalui pembuatan versi (versioning) atau negosiasi Prefer.
Apakah Anda menetapkan metrik peluncuran (rollout), kondisi berhenti (stop conditions), dan rollback di sisi server yang tidak memerlukan downgrade klien.
Apakah Anda mengetahui bahwa respons 204 berakhir setelah bagian headernya dan tidak dapat memuat konten atau trailer.

3. Pertanyaan yang Harus Dijawab Sebelum Migrasi

Klien mana yang selalu mengurai (parse) JSON, dan klien mana yang hanya memeriksa response.ok atau kelas 2xx?
Apakah objek keberhasilan tersebut benar-benar tidak dibaca, termasuk oleh pengumpul log, skrip gateway, dan tipe kembalian SDK yang dihasilkan?
Apakah klien dapat melakukan retry secara otomatis, sehingga mengubah operasi tulis yang berhasil tetapi diikuti oleh kesalahan parsing menjadi permintaan duplikat?
Apakah setiap klien dapat ditingkatkan versinya, atau apakah kedua kontrak harus tetap tersedia untuk jangka waktu yang lama?
Header mana, seperti ETag, field pembatasan laju (rate-limit), dan pengenal jejak (trace identifiers), yang harus tetap dipertahankan?

4. Kerangka Jawaban 30 Detik

Pertama-tama saya akan menyusun inventaris konsumen dan menggunakan pengujian kontrak untuk menemukan setiap dependensi pada body JSON 200. Selama migrasi, 200 tetap menjadi default. Klien yang kompatibel memilih untuk menggunakan respons minimal melalui versi API baru atau Prefer: return=minimal; ketika server memenuhinya, server akan mengembalikan 204 dan melaporkan Preference-Applied. Saya akan meluncurkannya secara bertahap mulai dari lalu lintas internal hingga ke versi klien berisiko rendah yang telah diketahui, sambil memantau kegagalan parsing, penulisan duplikat, percobaan ulang (retry), dan keberhasilan per klien. Rollback berupa peralihan server kembali ke 200 karena jalur serialisasi JSON tetap dipertahankan utuh hingga migrasi selesai.

5. Rencana Migrasi Bertahap

Langkah 1: Buat Inventaris Kemampuan Klien

Untuk setiap pemanggil, catat pemiliknya, versi, pustaka HTTP, pemeriksaan keberhasilan, parser respons, dan kebijakan percobaan ulangnya. Cari response.json() yang dipanggil tanpa syarat, perbandingan status === 200 yang persis, tipe kembalian SDK yang dihasilkan, dan pembacaan body.success di gateway. Pemanggil yang tidak dikenal atau tanpa versi tetap berada di 200. Tidak ada bukti kompatibilitas berarti tidak ada peluncuran 204.

Langkah 2: Buat Klien Menerima Kedua Kontrak Keberhasilan

Kirimkan (ship) dukungan klien terlebih dahulu. Klien yang kompatibel menerima respons 2xx yang disepakati, memeriksa 204 atau body kosong sebelum mengurai, dan memisahkan keberhasilan permintaan dari pendekodean JSON. Pengujian kontrak menyuplai baik 200 + JSON maupun 204 + empty body. Membalik urutan ini berisiko mengubah operasi tulis yang sukses menjadi kegagalan parsing yang terlihat oleh klien, yang kemudian memicu percobaan ulang duplikat.

Langkah 3: Pilih Cara Kedua Kontrak Hidup Berdampingan

Untuk perubahan yang sengaja merusak kompatibilitas mundur (breaking change), versi API baru selalu dapat mengembalikan 204 sementara versi lama tetap mempertahankan 200. Jika rute dan operasinya tetap sama, negosiasi preferensi RFC 7240 adalah opsi lain: klien yang kompatibel mengirimkan Prefer: return=minimal; server dapat memenuhinya dengan 204 dan Preference-Applied: return=minimal. Pemanggil yang membutuhkan representasi mengirimkan Prefer: return=representation atau mempertahankan perilaku default 200. Jika respons dapat di-cache, deklarasikan Vary: Prefer dengan benar.

Langkah 4: Luncurkan Berdasarkan Klien, Bukan Permintaan Acak

Aktifkan perilaku baru di lingkungan pengujian dan pemanggil internal terlebih dahulu, kemudian perluas hanya ke versi klien yang diketahui kompatibel. Pertahankan setiap klien atau akun dalam kohort yang stabil sehingga tidak berganti-ganti antara 200 dan 204. Amati siklus bisnis yang lengkap pada setiap tahap sebelum memperluasnya; metrik HTTP yang bersih dalam periode singkat saja tidak cukup.

Langkah 5: Amati Kegagalan yang Dapat Disebabkan oleh Perubahan Protokol

Di server, rincian hitungan 200, 204, 5xx, dan retry berdasarkan versi klien. Pada klien, catat kegagalan parsing body kosong, antarmuka pengguna kesalahan (error UI) yang ditampilkan setelah permintaan berhasil, dan pengiriman duplikat. Bandingkan operasi tulis yang selesai dengan percobaan ulang permintaan, terutama untuk operasi yang non-idempoten. Peringatan (alerts) harus mengidentifikasi versi klien dan kohort peluncuran; tingkat 2xx agregat menyembunyikan kegagalan kompatibilitas.

Langkah 6: Pertahankan Rollback Instan dan Tutup Migrasi

Pertahankan jalur serialisasi JSON asli di balik tombol switch server selama migrasi berlangsung. Jika kondisi berhenti terpicu, pulihkan 200 secara global; klien yang kompatibel ganda akan tetap berfungsi tanpa memerlukan downgrade. Hapus jalur lama hanya setelah setiap klien yang didukung berada di atas versi kompatibel minimum, lalu lintas lama tidak ada lagi selama jendela observasi yang disepakati, serta pengujian rangkaian SDK, proxy, dan kontrak tetap lulus.

6. Contoh Jawaban Berkualitas Tinggi

Saya akan memperlakukan ini sebagai migrasi kontrak respons. Pertama, saya akan menginventarisasi setiap konsumen dan menemukan kode yang selalu mengurai JSON, memeriksa secara presisi status 200, atau membaca body.success. Saya akan merilis klien yang menerima baik 200 JSON maupun 204 tanpa body sebelum mengubah perilaku server. Server mempertahankan 200 sebagai default; klien yang kompatibel memilih 204 melalui versi API atau Prefer: return=minimal, yang dikonfirmasi oleh Preference-Applied. Peluncuran berjalan berdasarkan versi klien, dengan kegagalan parsing, percobaan ulang (retry), dan penulisan duplikat sebagai sinyal utama. Jalur serialisasi 200 tetap tersedia sampai semua klien yang didukung telah bermigrasi, sehingga rollback berupa pengalihan di sisi server dan bukan melalui rilis klien.

7. Kesalahan Umum

Mengubah 200 langsung ke 204 → klien lama gagal saat mengurai body kosong → rilis klien yang kompatibel ganda sebelum mengaktifkan 204.
Hanya memantau tingkat kesalahan HTTP → 204 masih merupakan respons yang sukses, sehingga kegagalan parsing tidak muncul sebagai 5xx server → tambahkan metrik parsing klien, retry, dan penulisan duplikat.
Mengacak peluncuran per permintaan → satu klien menerima kontrak yang tidak stabil → kelompokkan berdasarkan versi klien atau identitas stabil lainnya.
Menerima Prefer tanpa melaporkan hasilnya → klien tidak dapat mengetahui apakah preferensi tersebut dipenuhi → kembalikan Preference-Applied dan tentukan perilaku defaultnya.
Langsung menghapus serialisasi JSON → rollback memerlukan rilis kode baru → pertahankan jalur lama hingga jendela migrasi ditutup.
Mengabaikan perilaku percobaan ulang otomatis → kesalahan parsing menyamarkan operasi tulis yang berhasil sebagai kegagalan → verifikasi kunci idempotensi (idempotency keys), middleware retry, dan metrik pengiriman duplikat.

8. Pertanyaan Lanjutan dan Tanggapannya

Pertanyaan Lanjutan 1: Mengapa tidak langsung mengalihkan semua klien sekaligus?

Server dapat membuktikan bahwa penulisan berhasil, tetapi tidak dapat membuktikan bahwa setiap klien yang terpasang menangani body 204 dengan benar. Satu versi lama yang selalu mengurai JSON akan mengubah keberhasilan di tingkat protokol menjadi kegagalan yang terlihat oleh pengguna. Memprioritaskan kompatibilitas klien terlebih dahulu, diikuti dengan peluncuran yang dicakup oleh versi, menjaga batasan kegagalan tetap dapat diobservasi.

Pertanyaan Lanjutan 2: Kapan Anda harus memilih versioning versus Prefer?

Versi baru cocok untuk pemutusan kontrak permanen dan mudah dipahami, tetapi menambah pekerjaan manajemen siklus hidup versi (version-lifecycle). Prefer cocok untuk operasi di mana representasi kembalian dan respons minimal sama-sama valid. Karena server dapat mengabaikan preferensi, klien membutuhkan perilaku default yang terdokumentasi dan harus memeriksa Preference-Applied. Keduanya lebih dapat diandalkan daripada menebak dari string User-Agent.

Pertanyaan Lanjutan 3: Informasi apa saja yang dapat dipertahankan oleh respons 204?

Respons ini dapat mempertahankan header seperti ETag, pengenal jejak (trace identifiers), dan field pembatasan laju (rate-limit). Respons ini tidak dapat memuat konten pesan atau trailer. Oleh karena itu, klien harus memperlakukan "tidak ada JSON" dan "tidak ada metadata" sebagai dua hal yang terpisah.

Pertanyaan Lanjutan 4: Kapan aman untuk menghapus jalur kompatibilitas 200?

Semua klien yang didukung harus telah merilis penanganan respons ganda, telemetri harus menunjukkan tidak ada lagi lalu lintas dari versi lama, serta pengujian SDK, proxy, otomatisasi, dan rollback harus lulus. Rilis app-store saja tidak cukup karena pengguna dapat tetap menggunakan versi yang lebih lama untuk jangka waktu yang lama.