Konteks dan cakupan
Pewawancara mungkin bertanya: “Apa arti dari respons interim HTTP 1xx dan 102 Processing? Jika sebuah request yang panjang membutuhkan umpan balik progres, bagaimana Anda akan mendesainnya?”
Sinyal yang dinilai adalah apakah Anda dapat memisahkan antara sinyal protokol bahwa request belum selesai, respons akhir, dan resource operasi asinkron. RFC 9110 mengizinkan nol atau lebih respons interim 1xx sebelum respons akhir non-1xx; hal ini tidak mengubah 102 menjadi protokol progres persentase generik. 102 berasal dari status WebDAV dalam RFC 2518 dan dihapus dari WebDAV oleh RFC 4918. Mulailah dengan memeriksa versi protokol, klien, dan perantara (intermediaries) sebelum mengusulkannya.
Hal yang diuji oleh pewawancara
- Apakah Anda mengetahui bahwa respons 1xx bersifat interim dan tidak menyelesaikan request.
- Apakah Anda dapat membedakan 100 Continue, 101 Switching Protocols, dan 102 Processing.
- Apakah Anda mengenali sejarah WebDAV dari 102 alih-alih menjanjikan dukungan universal.
- Apakah Anda dapat memilih 202 ditambah resource status, SSE, atau WebSocket untuk alur produk yang berjalan lama.
- Apakah Anda memperhitungkan proxy, batas waktu (timeout), percobaan ulang (retry), pembatalan, idempoten, dan pengambilan hasil.
Pertanyaan klarifikasi
- Apakah request harus tetap sinkron, atau pekerjaannya dapat menjadi operasi latar belakang?
- Apakah reverse proxy dan gateway akan meneruskan dan mengekspos respons 1xx?
- Apakah produk memerlukan petunjuk keep-alive, atau tahapan dan persentase yang dapat diobservasi?
- Apakah operasi tersebut memiliki efek samping yang dapat terulang akibat retry?
- Apakah ada resource hasil terpisah dengan masa kedaluwarsa dan kontrol akses?
Jawaban 30 detik
Anda dapat menjawab:
Respons 1xx bersifat interim; klien masih membutuhkan respons akhir non-1xx. 102 Processing berasal dari skenario operasi panjang WebDAV, sehingga ini bukan model progres umum dan tidak dapat diasumsikan dapat melewati setiap perantara. Jika pekerjaan dapat dilakukan secara asinkron, saya akan mengembalikan 202 dengan resource status terotorisasi yang mengekspos status stabil, error, pembatalan, dan tautan hasil. Jika koneksi harus tetap terbuka, saya akan mempertimbangkan SSE atau protokol event eksplisit lainnya berdasarkan dukungan klien, lalu menguji jalur proxy yang sebenarnya.
Penalaran langkah demi langkah
Tentukan siklus hidup respons
Pisahkan tahap interim dan akhir:
HTTP/1.1 102 Processing
HTTP/1.1 200 OK
Content-Type: application/json
{"result":"done"}102 tidak menyelesaikan request atau menjanjikan penyelesaian. Batasan penting dari RFC 9110 adalah respons akhir non-1xx tetap harus menyusul; hilangnya respons interim tidak secara otomatis membuktikan kegagalan bisnis.
Tentukan batasan untuk 102
RFC 2518 mendeskripsikan 102 sebagai petunjuk WebDAV selama operasi panjang, membantu klien menghindari anggapan bahwa koneksi aktif telah mati. Ini bukanlah resource alur kerja dengan percentComplete, nilai tahapan, dan semantik error yang terstandarisasi. RFC 4918 menghapus definisi WebDAV tersebut, sehingga API baru harus mendokumentasikan target implementasi dan kompatibilitasnya daripada hanya mengandalkan nomor status saja.
Pilih protokol untuk kebutuhan produk
Jika polling dapat diterima, pisahkan aksi dari statusnya: kembalikan 202 dan Location untuk pengiriman, lalu ekspos status stabil seperti Pending, Running, Succeeded, Failed, dan Canceled. Tambahkan SSE jika UI langsung membutuhkan pembaruan tahapan; evaluasi WebSocket hanya jika kontrol dua arah memang diperlukan. Setiap opsi membutuhkan rencana untuk koneksi ulang, backoff, pembatalan, dan otorisasi.
Tangani pengiriman duplikat dan penyelesaian akhir
Terima kunci idempoten untuk pembuatan dan simpan fingerprint request bersama dengan ID operasi. Percobaan ulang dengan kunci yang sama mengembalikan operasi yang sama alih-alih mengantrekan efek samping lainnya. Buat pembacaan status dapat diulang, lindungi URL hasil dengan pemeriksaan tenant dan masa kedaluwarsa, serta ekspos error terstruktur dengan batasan retry. Terputusnya koneksi, batas waktu, atau respons 102 bukanlah kesimpulan bisnis.
Contoh jawaban berkualitas tinggi
Pertama-tama saya akan membedakan petunjuk keep-alive dari progres yang dapat diobservasi. Jika request sinkron berisiko melebihi batas waktu gateway, saya tidak akan menggunakan 102 sebagai API progres generik: 1xx bersifat interim, 102 memiliki sejarah WebDAV, dan dukungan perantara tidak merata. Pilihan standar saya adalah memvalidasi pengiriman, mengembalikan 202 dengan ID operasi dan URL status, serta mengekspos informasi tahapan yang dibatasi, waktu pembaruan, error terstruktur, pembatalan, dan URL hasil. Pengiriman membawa kunci idempoten agar retry tidak membuat pekerjaan duplikat. Untuk UI langsung, saya dapat menambahkan SSE, dengan pemulihan melalui ID event terakhir atau resource status. Risiko keamanan atau kepatuhan tetap menggunakan jalur eskalasi dan audit formal. Ini menjaga sinyal protokol, status operasi, dan resource hasil tetap terpisah.
Kesalahan umum
- Menyebut 102 sebagai respons progres persentase tanpa kontrak field atau klien.
- Menganggap setiap 1xx sebagai keberhasilan atau izin untuk menutup koneksi.
- Mengabaikan penghapusan 102 dari WebDAV oleh RFC 4918 dan mengklaim dukungan WebDAV universal.
- Hanya membahas origin server sambil melewatkan pengujian CDN, proxy, gateway, dan browser.
- Mengembalikan 202 tanpa resource status, strategi idempoten, status kegagalan, atau otorisasi hasil.
- Memperlakukan koneksi terputus, batas waktu, atau retry sebagai bukti kegagalan dan menduplikasi efek samping.
Pertanyaan lanjutan dan jawabannya
1. Apa perbedaan utama antara 102 dan 202?
102 adalah respons interim untuk request yang sama; respons akhir masih tertunda. 202 adalah respons akhir yang menyatakan bahwa request telah diterima untuk diproses, meskipun hasilnya mungkin belum siap. Untuk pekerjaan yang dapat diobservasi dan dipulihkan secara independen, 202 ditambah resource status biasanya lebih jelas.
2. Bagaimana jika proxy tidak meneruskan respons 1xx?
Perlakukan 1xx sebagai optimasi opsional, jangan pernah menjadikannya satu-satunya sinyal kebenaran. Sediakan status yang dapat dipulihkan melalui endpoint status, SSE, atau jalur klien yang terkontrol, dan uji rantai perantara yang sebenarnya.
3. Kapan Anda masih akan menggunakan 102?
Hanya jika seluruh rangkaian stack secara eksplisit mendukungnya, persyaratannya adalah petunjuk interim untuk request panjang yang sama, dan tim menerima batasan kompatibilitasnya. Catat bukti klien, proxy, dan batas waktu, serta pertahankan fallback yang benar yang berfungsi tanpa 102.