Apakah salah untuk menampilkan 202 "Diterima" sebagai tanggapan terhadap HTTP GET?

90

Saya memiliki satu set resource yang representasi dibuat dengan malas. Komputasi untuk membuat representasi ini dapat berlangsung dari beberapa milidetik hingga beberapa jam, bergantung pada beban server, sumber daya tertentu, dan fase bulan.

Permintaan GET pertama yang diterima untuk sumber daya memulai komputasi di server. Jika komputasi selesai dalam beberapa detik, representasi yang dihitung dikembalikan. Jika tidak, kode status 202 "Diterima" dikembalikan, dan klien harus mengumpulkan sumber daya hingga representasi akhir tersedia.

Alasan perilaku ini adalah sebagai berikut: Jika hasil tersedia dalam beberapa detik, hasilnya harus diambil secepat mungkin; sebaliknya, saat tersedia tidak penting.

Karena memori yang terbatas dan volume permintaan yang sangat banyak, baik NIO maupun polling yang lama tidak menjadi pilihan ( yaitu, saya hampir tidak dapat menjaga koneksi yang cukup terbuka, bahkan saya juga tidak dapat memasukkan semua permintaan dalam memori; sekali "beberapa detik" telah berlalu, saya mempertahankan permintaan berlebih). Demikian pula, batasan klien sedemikian rupa sehingga mereka tidak dapat menangani callback penyelesaian. Terakhir, perhatikan bahwa saya tidak tertarik untuk membuat sumber daya "pabrik" yang diposkan oleh satu POST, karena perjalanan bolak-balik ekstra berarti kita gagal dalam kendala waktu nyata sedikit demi sedikit lebih dari yang diinginkan (selain itu, ini adalah kerumitan ekstra; juga, ini adalah sumber daya yang akan manfaat dari caching).

Saya membayangkan ada beberapa kontroversi dalam mengembalikan kode status 202 "Diterima" sebagai tanggapan atas permintaan GET, mengingat saya belum pernah melihatnya dalam praktiknya, dan penggunaannya yang paling intuitif adalah sebagai tanggapan terhadap metode yang tidak aman, tetapi saya tidak pernah menemukan sesuatu yang secara khusus mengecilkan hati. Selain itu, apakah saya tidak menjaga keamanan dan idempotensi?

Jadi, apa pendapat orang tentang pendekatan ini?

EDIT : Saya harus menyebutkan ini untuk apa yang disebut API web bisnis - bukan untuk browser.

http-status-codes  http-get 
— pengguna359996
sumber
2
Saya pribadi berpikir itu bagus, itu persis definisi dari a 202. Itu jarang digunakan dalam praktiknya adalah IMHO lebih karena sedikit pengembang web yang peduli dengan kode status yang tepat karena mereka lebih terbiasa dengan interaksi browser / agen pengguna dalam hal ini a tidak 202memberi mereka petunjuk yang terlihat (beri mereka a 200dan mereka senang. ..).
— Wrikken
1
@ user359996, gunakan saja 200. 202adalah apa yang seharusnya , tetapi dalam praktiknya orang tidak berharap 202.
— Pacerier
perlu ETA untuk 200 agar berguna dalam praktiknya.
— Rob

Jawaban:

66

Jika itu untuk API yang didefinisikan dengan baik dan -documented, 202suara persis tepat untuk apa yang terjadi.

Jika itu untuk Internet publik, saya akan terlalu khawatir tentang kompatibilitas klien. Saya telah melihat begitu banyak if (status == 200)hard-coded .... Dalam hal ini, saya akan mengembalikan file 200.

Juga, RFC tidak membuat indikasi bahwa menggunakan 202 untuk permintaan GET adalah salah, sementara RFC membuat perbedaan yang jelas dalam deskripsi kode lainnya (misalnya 200).

Permintaan telah diterima untuk diproses, tetapi pemrosesan belum selesai.

— Pekka
sumber
17

Kami melakukan ini untuk aplikasi terbaru, klien (aplikasi kustom, bukan browser) POST kueri dan server akan mengembalikan 202 dengan URI ke "pekerjaan" yang sedang diposting - klien akan menggunakan URI itu untuk mengumpulkan hasilnya - ini tampaknya cocok dengan apa yang telah dilakukan.

Yang paling penting di sini adalah mendokumentasikan cara kerja layanan / API Anda, dan apa arti dari respons 202.

— no
sumber
+1 Terima kasih atas komentar Anda. Poin bagus tentang dokumentasi. Namun harap perhatikan hasil edit klarifikasi pada pertanyaan saya (cari "pabrik").
— pengguna359996
Nah, Anda bisa menghilangkan URI itu dalam respons jika Anda hanya ingin melakukan polling URI yang sama seperti yang Anda minta. (Cukup dokumentasikan bagaimana ini seharusnya bekerja :-))
— no
Ide bagus, tapi ingat saya ingin caching, jadi tidak ada POST. Selain itu, URI menentukan sumber daya, bukan metode. Saya mengambil pendekatan RESTful, daripada RPC (maaf, kendala lain yang tidak ditentukan - saya buruk).
— pengguna359996
Tepatnya, dengan "RESTful", yang saya maksud adalah "berorientasi sumber daya", yang secara teknis sedikit lebih dari yang ditentukan oleh batasan REST.
— pengguna359996
Ini juga didukung oleh "1.10 How to Use POST for Asynchronous Tasks" oleh buku " RESTful Web Services Cookbook " oleh Subbu Allamraju
— koppor
12

Dari apa yang saya ingat - GET seharusnya mengembalikan sumber daya tanpa memodifikasi server. Mungkin aktivitas akan dicatat atau apa yang Anda miliki, tetapi permintaan harus dapat dijalankan kembali dengan hasil yang sama.

POST di sisi lain adalah permintaan untuk mengubah status sesuatu di server. Masukkan catatan, hapus catatan, jalankan pekerjaan, sesuatu seperti itu. 202 akan sesuai untuk POST yang dikembalikan tetapi belum selesai, tetapi bukan permintaan GET.

Semuanya sangat puritan dan tidak dipraktikkan dengan baik di alam liar, jadi Anda mungkin aman dengan mengembalikan 202. GET harus mengembalikan 200. POST dapat mengembalikan 200 jika selesai atau 202 jika belum selesai.

http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html

— Dlongnecker
sumber
4
Pemikiran yang sangat baik tetapi saya tidak yakin apakah itu berlaku di sini: Dari apa yang dikatakan OP, ini tampaknya merupakan permintaan GET yang tepat (karena tidak mengubah apa pun di server), hanya perlu waktu lebih lama untuk menghitung dan masuk kasus itu, harus diambil di lain waktu. Mungkin OP bisa memberikan komentar yang berwibawa. Ini untuk API jadi tidak masalah menjadi "puritan" demi antarmuka yang bersih
— Pekka
Oh, sentuh pekka. Anda benar, GET adalah jalan yang harus ditempuh. Dan menurut saya HTTP spc tidak benar-benar memperhitungkan GET yang belum siap. Jadi dia bisa pergi ke arah mana pun
— Dlongnecker
7
Komentar otoritatif (Sekarang tidak relevan): Ya, saya melihat ini sebagai idempoten. Sumber daya tidak sedang dimodifikasi atau dibuat, melainkan representasinya belum dihitung.
— pengguna359996
1
Dimana dikatakan demikian? Juga, jika saya mengembalikan 200, klien harus mengharapkan representasi telah dikembalikan, tetapi ternyata belum.
— pengguna359996
1
Saya ambil kembali. 202 tidak sesuai dengan hanya GET atau POST tampaknya. Hanya pola pikir saya ketika saya melihat protokol membuat saya hal 202 hanya ada untuk permintaan GET. 202 seharusnya bagus untuk tujuan Anda.
— Dlongnecker
0

Dalam kasus sumber daya yang seharusnya memiliki representasi entitas yang secara jelas ditentukan oleh ID (sebagai lawan dari sumber daya "pabrik", seperti yang dijelaskan dalam pertanyaan), saya sarankan untuk tetap menggunakan metode GET dan, dalam situasi ketika entitas / representasi tidak tersedia karena pembuatan lambat atau situasi sementara lainnya, gunakan kode respons 503 Layanan Tidak Tersedia yang lebih sesuai dan sebenarnya dirancang untuk situasi seperti ini.

Alasan untuk ini dapat ditemukan di RFC untuk HTTP itu sendiri (harap verifikasi deskripsi kode tanggapan 503), serta di berbagai sumber lainnya.

Silakan bandingkan dengan kode status HTTP untuk sementara halaman tidak tersedia . Meskipun pertanyaan itu tentang kasus penggunaan yang berbeda, sebenarnya ini berkaitan dengan fitur HTTP yang sama persis.

— Hermes
sumber
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.