Gesaan dan skop
Penemu duga mungkin bertanya: “Apakah maksud respons interim HTTP 1xx dan 102 Processing? Jika permintaan yang panjang memerlukan maklum balas kemajuan, bagaimanakah anda mereka bentuknya?”
Isyarat yang dinilai ialah sama ada anda boleh memisahkan isyarat protokol bahawa permintaan belum selesai, respons akhir, dan sumber operasi tak segerak (asynchronous). RFC 9110 membenarkan sifar atau lebih respons interim 1xx sebelum respons akhir bukan 1xx; ia tidak menjadikan 102 sebagai protokol kemajuan peratusan generik. 102 berasal sebagai status WebDAV dalam RFC 2518 dan telah dialih keluar daripada WebDAV oleh RFC 4918. Mulakan dengan menyemak versi protokol, klien dan perantara (intermediaries) sebelum mencadangkannya.
Perkara yang diuji oleh penemu duga
- Sama ada anda tahu bahawa respons 1xx adalah interim dan tidak melengkapkan permintaan.
- Sama ada anda boleh membezakan antara 100 Continue, 101 Switching Protocols, dan 102 Processing.
- Sama ada anda mengenali sejarah WebDAV bagi 102 dan bukannya menjanjikan sokongan universal.
- Sama ada anda boleh memilih 202 berserta sumber status, SSE, atau WebSocket untuk aliran produk jangka panjang.
- Sama ada anda mengambil kira proksi, had masa tamat (timeouts), percubaan semula (retries), pembatalan, keidempotetan (idempotency), dan pengambilan hasil.
Soalan penjelasan
- Adakah permintaan mesti kekal segerak (synchronous), atau bolehkah kerja tersebut menjadi operasi latar belakang?
- Adakah proksi terbalik dan get laluan akan memajukan dan mendedahkan respons 1xx?
- Adakah produk memerlukan petunjuk kekal hidup (keep-alive), atau peringkat dan peratusan yang boleh diperhatikan?
- Adakah operasi tersebut mempunyai kesan sampingan yang boleh diulangi oleh percubaan semula?
- Adakah terdapat sumber hasil yang berasingan dengan tempoh tamat dan kawalan akses?
Jawapan 30 saat
Anda boleh menjawab:
Respons 1xx adalah interim; klien masih memerlukan respons akhir bukan 1xx. 102 Processing berasal daripada senario operasi panjang WebDAV, jadi ia bukan model kemajuan umum dan tidak boleh diandaikan dapat merentasi setiap perantara. Jika kerja boleh dilakukan secara tak segerak, saya akan mengembalikan 202 dengan sumber status sah yang mendedahkan keadaan stabil, ralat, pembatalan dan pautan hasil. Jika sambungan mesti kekal terbuka, saya akan mempertimbangkan SSE atau protokol peristiwa eksplisit lain berdasarkan sokongan klien, kemudian menguji laluan proksi yang sebenar.
Penaakulan langkah demi langkah
Tentukan kitaran hayat respons
Asingkan peringkat interim dan akhir:
HTTP/1.1 102 Processing
HTTP/1.1 200 OK
Content-Type: application/json
{"result":"done"}102 tidak menyelesaikan permintaan atau menjanjikan penyiapan. Kekangan penting RFC 9110 ialah respons akhir bukan 1xx masih menyusul; kehilangan respons interim tidak membuktikan kegagalan perniagaan secara tersendiri.
Tetapkan sempadan untuk 102
RFC 2518 menerangkan 102 sebagai petunjuk WebDAV semasa operasi panjang, membantu klien mengelak daripada menganggap sambungan aktif telah mati. Ia bukan sumber aliran kerja dengan percentComplete, nilai peringkat dan semantik ralat yang diseragamkan. RFC 4918 mengalih keluar takrifan WebDAV tersebut, jadi API baharu mesti mendokumenkan pelaksanaan sasaran dan keserasian dan bukannya bergantung pada nombor itu semata-mata.
Pilih protokol untuk keperluan produk
Apabila pengundian (polling) boleh diterima, asingkan tindakan daripada statusnya: kembalikan 202 dan Location untuk penyerahan, kemudian dedahkan keadaan stabil seperti Pending, Running, Succeeded, Failed, dan Canceled. Tambahkan SSE apabila UI langsung memerlukan kemas kini peringkat; nilaikan WebSocket hanya apabila kawalan dwiarah adalah wajar. Setiap pilihan memerlukan pelan untuk penyambungan semula, backoff, pembatalan dan kebenaran.
Kendalikan penyerahan pendua dan penyiapan akhirnya
Terima kunci keidempotetan untuk penciptaan dan simpan cap jari permintaan bersama ID operasi. Percubaan semula dengan kunci yang sama mengembalikan operasi yang sama dan bukannya menambah satu lagi kesan sampingan ke dalam barisan gilir. Jadikan bacaan status boleh diulang, lindungi URL hasil dengan semakan penyewa dan tempoh tamat, dan dedahkan ralat berstruktur dengan sempadan percubaan semula. Sambungan terputus, masa tamat, atau respons 102 bukan kesimpulan perniagaan.
Model jawapan berkualiti tinggi
Saya mula-mula akan membezakan petunjuk kekal hidup daripada kemajuan yang boleh diperhatikan. Jika permintaan segerak mungkin melebihi had masa tamat get laluan, saya tidak akan menggunakan 102 sebagai API kemajuan generik: 1xx adalah interim, 102 mempunyai sejarah WebDAV, dan sokongan perantara tidak sekata. Pilihan lalai saya adalah untuk mengesahkan penyerahan, mengembalikan 202 dengan ID operasi dan URL status, serta mendedahkan maklumat peringkat yang terhad, masa kemas kini, ralat berstruktur, pembatalan dan URL hasil. Penyerahan membawa kunci keidempotetan supaya percubaan semula tidak mencipta kerja pendua. Untuk UI langsung, saya boleh menambah SSE, dengan pemulihan melalui ID peristiwa terakhir atau sumber status. Risiko keselamatan atau pematuhan masih menggunakan laluan peningkatan dan audit rasmi. Ini memastikan isyarat protokol, status operasi dan sumber hasil kekal berasingan.
Kesilapan lazim
- Memanggil 102 sebagai respons kemajuan peratusan tanpa kontrak medan atau klien.
- Menganggap sebarang 1xx sebagai kejayaan atau kebenaran untuk menutup sambungan.
- Mengabaikan pengalihan keluar 102 daripada WebDAV oleh RFC 4918 dan mendakwa sokongan WebDAV sejagat.
- Hanya membincangkan pelayan asal sambil melangkau ujian CDN, proksi, get laluan dan pelayar.
- Mengembalikan 202 tanpa sumber status, strategi keidempotetan, status kegagalan atau kebenaran hasil.
- Menganggap sambungan terputus, masa tamat atau percubaan semula sebagai bukti kegagalan dan menduplikasi kesan sampingan.
Soalan susulan dan respons
1. Apakah perbezaan utama antara 102 dan 202?
102 ialah respons interim untuk permintaan yang sama; respons akhir masih belum selesai. 202 ialah respons akhir yang menyatakan bahawa permintaan telah diterima untuk pemprosesan, manakala hasilnya mungkin belum siap. Bagi kerja yang boleh diperhatikan dan dipulihkan secara bebas, 202 berserta sumber status biasanya lebih jelas.
2. Bagaimana jika proksi tidak memajukan respons 1xx?
Anggap 1xx sebagai pengoptimuman pilihan, jangan sekali-kali menjadikannya satu-satunya isyarat ketepatan. Sediakan status yang boleh dipulihkan melalui titik akhir status, SSE, atau laluan klien terkawal, dan uji rantaian perantara yang sebenar.
3. Bilakah anda masih akan menggunakan 102?
Hanya apabila tindanan hujung ke hujung menyokongnya secara eksplisit, keperluannya ialah petunjuk interim untuk permintaan panjang yang sama, dan pasukan menerima sempadan keserasian tersebut. Rekod bukti klien, proksi dan masa tamat, serta kekalkan sandaran betul yang berfungsi tanpa 102.