Wawancara backend: Bagaimana seharusnya HTTP Prefer menegosiasikan respons tanpa merusak idempotensi dan caching?

Konteks dan cakupan

Sebuah batch write API melayani klien dengan tujuan bandwidth dan latensi yang berbeda: beberapa hanya membutuhkan status, beberapa membutuhkan representasi sumber daya yang lengkap, dan beberapa bersedia menunggu beberapa detik untuk menghindari polling. Dengan menggunakan RFC 7240, rancang header permintaan Prefer, header respons Preference-Applied, penanganan kesalahan, caching, dan perilaku fallback.

Prefer adalah preferensi permintaan, bukan mandat server. Pertanyaan ini menguji semantik protokol dan kontrak API; ini tidak mengasumsikan setiap proxy mempertahankan header preferensi.

Apa yang sedang diuji oleh pewawancara

Apakah Anda membedakan preferensi klien dari janji server dan melaporkan apa yang sebenarnya diterapkan.
Apakah Anda menggunakan return=minimal, return=representation, respond-async, dan wait dengan benar.
Apakah Anda memperhitungkan varian respons, Vary, kunci cache, dan kompatibilitas proxy.
Apakah percobaan ulang (retry), kunci idempotensi, dan status tugas asinkron tetap aman saat preferensi tidak dipenuhi.

Pertanyaan klarifikasi

Apakah API ini merupakan operasi baca yang aman (safe read) atau tulis yang menimbulkan efek samping (side-effecting write), dan apakah API ini sudah memiliki kunci idempotensi?
Berapa ukuran, biaya pembuatan, dan waktu tunggu maksimum untuk representasi lengkap?
Bisakah klien menerima 202 dan sumber daya status, polling, atau panggilan balik (callback)?
Apakah middlebox akan meneruskan Prefer, dan bisakah cache dibagikan (shared)?
Bidang stabil mana yang harus dilihat klien ketika preferensi tidak dipenuhi?

Jawaban 30 detik

“Prefer menyatakan preferensi klien yang dapat diabaikan atau diterapkan sebagian oleh server; Preference-Applied melaporkan apa yang diterapkan. Operasi tulis dapat menggunakan return=minimal untuk memperkecil respons, pemanggil sinkron dapat meminta return=representation, dan operasi yang panjang dapat menggunakan respond-async dengan batas wait. Saya akan merancang kunci idempotensi, sumber daya status 202, cache Vary, dan fallback klien secara bersamaan: tanpa Preference-Applied, uraikan respons default dan jangan pernah berasumsi preferensi tersebut berhasil.”

Desain langkah demi langkah

1. Perlakukan preferensi sebagai negosiasi yang dapat diabaikan

RFC 7240 mendefinisikan header permintaan Prefer dan header respons Preference-Applied. Server dapat menolak preferensi, sehingga body dan kode status memerlukan kontrak default yang stabil. Klien tidak boleh melewatkan proses penguraian (parsing) hanya karena telah mengirimkan Prefer.

2. Pilih token preferensi yang tepat

return=minimal cocok untuk operasi tulis yang hanya memerlukan konfirmasi; return=representation cocok untuk pemanggil sinkron yang memerlukan sumber daya yang diperbarui. respond-async menyatakan bahwa klien menerima pemrosesan asinkron, sementara wait=n memberikan anggaran waktu tunggu. Ini adalah petunjuk (hint), bukan jaminan SLA.

3. Konfirmasikan hasilnya dalam respons

Kirimkan Preference-Applied ketika preferensi digunakan. Jika tidak digunakan, header tersebut mungkin tidak ada dan kontrak default berlaku. Jalur asinkron mengembalikan 202, URI status, dan ID yang dapat dilacak; setelah anggaran tunggu sinkron kedaluwarsa, operasi tetap dapat di-query daripada menyebabkan klien mengirim ulang efek samping.

http

POST /v1/imports HTTP/1.1
Prefer: return=minimal, respond-async, wait=3
Idempotency-Key: imp-8f2

HTTP/1.1 202 Accepted
Preference-Applied: respond-async
Location: https://api.example/imports/jobs/42
Cache-Control: no-store

4. Tangani varian cache

Jika representasi GET yang aman bervariasi dengan Prefer, deklarasikan Vary dengan benar atau jauhkan respons yang bergantung pada preferensi dari shared cache. Operasi tulis biasanya menggunakan no-store. Sumber daya status asinkron harus mendefinisikan caching singkat, ETag, atau kondisi polling eksplisit agar middlebox tidak mengembalikan progres yang usang.

5. Pertahankan idempotensi dan fallback

Prefer tidak mengubah semantik operasi, jadi percobaan ulang tetap memerlukan idempotensi. Gunakan kunci idempotensi atau deduplikasi bisnis untuk operasi tulis. Jika klien melihat 202, batas waktu habis (timeout), atau tidak ada Preference-Applied, klien harus melakukan query pada tugas tersebut atau mengikuti kontrak respons default daripada membuat sumber daya lagi.

6. Tetapkan observabilitas dan batas

Catat token preferensi, apakah token tersebut diterapkan, durasi tunggu, ukuran respons, tingkat 202, dan jalur proxy. Beri batasan pada wait, menolak atau memotong nilai yang berlebihan. Abaikan dan catat preferensi yang tidak dikenal alih-alih mengubah string klien sembarangan menjadi jalur eksekusi yang mahal.

Contoh jawaban berkualitas tinggi

“Saya akan memperlakukan Prefer sebagai preferensi klien yang dapat diabaikan, bukan sebuah janji. Operasi tulis secara default menghasilkan status yang stabil; klien yang menginginkan respons kecil mengirimkan return=minimal, yang membutuhkan sumber daya mengirimkan return=representation, dan tugas yang panjang menggunakan respond-async dengan batas wait. Server hanya mengirimkan Preference-Applied ketika menerapkan preferensi tersebut; hasil asinkron adalah 202 dengan Location dan ID tugas. Operasi tulis menggunakan kunci idempotensi, respons menggunakan no-store jika sesuai, dan perbedaan representasi diisolasi dengan Vary atau kebijakan cache. Tanpa Preference-Applied, klien mengikuti parser default dan melakukan query terhadap tugas, tidak pernah menduplikasi efek samping.”

Kesalahan umum

Memperlakukan Prefer sebagai hal wajib → server dan proxy mungkin mengabaikannya → gunakan kontrak default dan Preference-Applied.
Memperlakukan waktu tunggu sebagai jaminan penyelesaian → tugas yang panjang masih dapat melampauinya → batasi anggaran waktu dan sediakan sumber daya status 202.
Mengirim ulang setelah waktu tunggu asinkron habis → menghasilkan efek samping duplikat → gunakan kunci idempotensi dan lakukan query terlebih dahulu.
Mengabaikan varian cache → klien menerima representasi yang tidak cocok → atur Vary atau isolasi cache.
Mengeksekusi preferensi tidak dikenal yang sembarangan → penyerang dapat melipatgandakan biaya sumber daya → abaikan, catat, dan batasi token.

Pertanyaan lanjutan dan tanggapan

Apakah Preference-Applied yang hilang berarti permintaan tersebut gagal?

Tidak. Server dapat memilih perilaku default-nya atau mengabaikan preferensi tersebut. Klien harus menguraikan kontrak default yang stabil dan hanya menganggapnya sebagai kegagalan jika protokol atau status bisnis menyatakan bahwa itu gagal.

Bisakah setiap operasi tulis menggunakan return=minimal?

Tidak. Ini hanya menyatakan bahwa klien tidak memerlukan representasi lengkap. Jika klien memerlukan versi yang dibuat server, digest, atau tautan berikutnya, klien harus meminta representasi atau mengambil sumber daya tersebut daripada menyimpulkan kolom-kolom dari respons yang kosong.

Apakah wait=5 membuat server memblokir (block) selama lima detik?

Tidak ada jaminan pasti yang menyertainya. Ini adalah preferensi batas atas waktu tunggu dari klien; server dapat selesai lebih awal, mengabaikannya, atau beralih ke asinkron. Batas waktu server, batas konkurensi, dan anggaran sumber daya tetap berlaku.