WebClient vs. HttpWebRequest / HttpWebResponse


132

Tampak bagi saya bahwa sebagian besar dari apa yang dapat dicapai dengan HttpWebRequest/Responsejuga dapat dicapai dengan WebClientkelas. Saya membaca di suatu tempat yang WebClientmerupakan pembungkus tingkat tinggi untuk WebRequest/Response.
Sejauh ini, saya tidak bisa melihat apa pun yang dapat diselesaikan dengan HttpWebRequest/Responseyang tidak dapat dicapai dengan WebClient, atau di mana HttpWebRequest / Response akan memberi Anda lebih banyak kontrol "halus".

Kapan saya harus menggunakan WebClient dan kapan HttpWebRequest/Response? (Jelas, HttpWebRequest/Responseadalah HTTP spesifik.)

Jika HttpWebRequest/Responselevelnya lebih rendah WebClient, apa yang bisa saya capai dengan HttpWebRequest/Responseyang tidak bisa saya capai WebClient?

Jawaban:


87

Menggunakan HttpWebRequestmemberi Anda lebih banyak kontrol pada permintaan. Anda dapat mengatur cookie, tajuk, protokol, dll ... Dalam respons, Anda juga dapat mengambil cookie dan tajuk


14
Thomas, masih belum yakin ... WebClient memiliki properti Header, Anda dapat mengambil cookie seperti ini: String cookie = webClient.ResponseHeaders ("Set-Cookie") dan mengaturnya: webClient.Headers.Add ("Cookie", " CommunityServer-UserCookie ... ");
Dan

14
Menggunakan HttpWebRequest Anda dapat menentukan batas waktu. Di WebClient, itu tidak mungkin.
ripper234

14
@ ripper234, sebenarnya itu adalah mungkin: Anda hanya perlu mewarisi WebClient dan menimpa GetWebRequest untuk menyesuaikan HttpWebRequest
Thomas Levesque

15
@ThomasLevesque jika Anda mewarisi klien web dan mengabaikan permintaan web, tampaknya tidak ada gunanya menggunakan klien web ...
Hagai L

5
@HagaiL, saya tidak setuju ... Anda tidak harus membuat seluruh permintaan secara manual, Anda dapat menggunakannya base.GetWebRequestuntuk membuatnya dan kemudian menyesuaikan apa yang Anda inginkan
Thomas Levesque

54

HttpWebRequest memperlihatkan lebih banyak hal yang memungkinkan Anda mengontrol protokol berbutir halus, misalnya: apakah Anda ingin menggunakan Keep-Alive, kumpulan koneksi apa yang digunakan, apakah buffer menulis atau tidak, dll.

WebClienttidak mengekspos semua itu (meskipun Anda dapat subkelas dari WebClientdan mendapatkan akses ke objek Permintaan yang mendasarinya).

WebClientberguna untuk situasi di mana Anda hanya ingin melakukan operasi (misalnya: POST / GET / Form upload) dan tidak dapat diganggu untuk membuat dan mengelola HttpWebRequest, RequestStream, HttpWebResponse, dan aliran respons.


13
Juga, ada satu hal lagi yang saya lupa sebutkan. WebClient adalah objek Komponen, sedangkan HttpWebRequest tidak. Apa artinya? Nah, jika Anda menggunakan VisualStudio untuk membangun aplikasi GUI, maka Anda dapat menarik / melepaskan komponen WebClient di formulir Anda dan menggunakannya untuk mengeluarkan permintaan ke server HTTP / FTP dll.
feroze

14

Dari blog Tim Heuer - http://timheuer.com/blog/archive/2008/03/14/calling-web-services-with-silverlight-2.aspx

Sebaliknya di Silverlight Anda ingin menggunakan WebClient atau HttpWebRequest. Apa bedanya? Inilah versi timheuer. WebClient adalah implementasi sederhana yang melakukan permintaan GET dengan sangat mudah dan mendapatkan aliran respons. HttpWebRequest sangat bagus untuk ketika Anda memerlukan sedikit kontrol granular atas permintaan, perlu mengirim header atau penyesuaian lainnya.


7
WebClient juga memungkinkan POST, dengan UploadString, UploadData dan UploadFile
Thomas Levesque

@ThomasLevesque Apakah ada versi kelas yang lebih baru hari ini? Saya melihat bahwa diskusi ini agak, hmm ... berumur ...
Konrad Viltersten

@KonradViltersten, saya tidak berpikir ada banyak perubahan pada kelas WebClient. Untuk aplikasi baru, saya sarankan Anda menggunakan HttpClient, yang juga sangat mudah digunakan dan jauh lebih fleksibel.
Thomas Levesque

1
@ThomasLevesque Benar, bahwa adalah salah satu yang saya pikirkan. Saya mengingat http sebagai perbedaan dalam nama kelas dan disesatkan oleh Http ... sebagian. Sekarang saya kembali ke jalur yang benar. Terima kasih!
Konrad Viltersten

12

Kelas WebClient berjalan pada utas antarmuka pengguna, sehingga antarmuka pengguna tidak responsif saat data sedang diunduh dari Internet. Di sisi lain, kelas HttpWebRequest tidak memblokir utas antarmuka pengguna, dan aplikasi Anda responsif. Jadi, di aplikasi tempat sejumlah besar data harus diunduh dari Internet atau jika sumber data lambat diakses, Anda harus menggunakan kelas HttpWebRequest; dalam semua kasus lain, Anda harus menggunakan kelas WebClient.


1
Yang sebaliknya berlaku di WP7. HttpWebRequest marshal kembali ke utas UI di Mango, menyebabkan saya tidak ada habisnya kesedihan sekarang. Grrr
Cameron MacFarland

6
WebClient juga mendukung metode asinkron.
CyberMonk

6

Kelemahan lain dari WebClientitu mengabaikan HTTP ContentType's charsetnilai ketika Anda menggunakannya untuk mendapatkan teks respon. Anda harus mengatur penyandian melalui Encodingproperti secara eksplisit .


Ini adalah poin yang bagus; dan itu bukan hanya masalah pengaturan Encoding- Anda tidak dapat mengetahui pengkodean sampai setelah permintaan, sehingga api WebClient membuatnya sangat tidak mungkin Anda akan dapat mengunduh string dengan benar dalam pengkodean yang tidak dikenal.
Eamon Nerbonne


5

"HtttpWebRequest" sudah usang di .NET 4.5. Sekarang, kelas ini hanya internal.


2
Memang. Gunakan WebRequestsebagai gantinya.
Silkfire

2
Kelas tidak usang, konstruktornya sudah usang. Dan kelas tidak internal, masih publik.
user247702

2

Satu contoh: Mem-posting data dan mendapatkan kembali data yang diproses dalam satu siklus permintaan / respons tampaknya tidak mungkin dilakukan dengan WebClient, tetapi Anda dapat melakukannya dengan HtttpWebRequest.


2
Cukup gunakan WebClient.UploadString atau WebClient.UploadData untuk melakukan POST dan mendapatkan kembali string respons atau byte array.
samjudson

2
Untuk memperjelas, nilai kembali dari UploadString adalah string dan nilai kembali dari metode UploadData adalah array byte.
Norman H
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.