In the current project, team decided to limit UI automation as we are working on the Most Viable Product (MVP) and based on the beta users feedback,UI might change for the final product.In this regard, as part of integration tests we targeted automation at WebAPI level. On.Net platform we have HttpClient,WebClient and RestSharp client libraries.This link has nice explanation of available. WebClient vs HttpClient vs HttpWebRequest vs RestSharp Standard. This is the standard class that the.NET creators originally developed to consume HTTP requests. Using HttpWebRequest gives you control over every aspect of the request/response object, like timeouts, cookies, headers, protocols.
I plan to read a remote file line by line asynchronously using https://github.com/Dasync/AsyncEnumerable (since there is not yet Async Streams [C# 8 maybe]: https://github.com/dotnet/csharplang/blob/master/proposals/async-streams.md):
It seems that they both run just fine in a simple Console application like below:
... but I have some concerns if it is used as part of an ASP.NET Core WebAPI to process the lines and then push them using PushStreamContent:
The idea would be to have a pipeline of data which leverages
async
/ await
so that the number of threads in use is as low as possible and also to avoid an increase in memory (which leverage the enumerable-like feature of AsyncEnumerable).I read several articles but it seems it's all non .NET Core versions and I don't really know if there would be some potential performance issues / caveats in regard to what I would like to achieve?
An example of 'business' case would be:
Ehouarn Perret
Ehouarn PerretEhouarn Perret1,63622 gold badges1414 silver badges3636 bronze badges
1 Answer
We have access to the source code for .NET Core. So you can look.
The underlying implementation of both end up using
HttpClientHandler
(the implementation of that class is split up into 4 files).You can see this from the source code of both
HttpClient
and HttpWebRequest
(which WebRequest
uses).So I suspect you won't notice any difference in the performance of either.
HttpClient
is the latest one to be written, so that's why its use is encouraged. And for the reasons mentioned in the article you linked to: http://www.diogonunes.com/blog/webclient-vs-httpclient-vs-httpwebrequest/12.1k11 gold badge1616 silver badges2727 bronze badges
Got a question that you can’t ask on public Stack Overflow? Learn more about sharing private information with Stack Overflow for Teams.
Not the answer you're looking for? Browse other questions tagged c#asp.net-core.net-coredotnet-httpclientwebrequest or ask your own question.
Our web app is running in .Net Framework 4.0. The UI calls controller methods through ajax calls.
We need to consume REST service from our vendor. I am evaluating the best way to call REST service in .Net 4.0. The REST service requires Basic Authentication Scheme and itcan return data in both XML and JSON. There is no requirement for uploading/downloading huge data and I don't see anything in future. I took a look at few open source code projects for REST consumption and didn't find any value in those to justify additional dependency in the project. Started to evaluate
WebClient
and HttpClient
. I downloaded HttpClient for .Net 4.0 from NuGet. I searched for differences between
WebClient
and HttpClient
and this site mentioned that single HttpClient can handle concurrent calls and it can reuse resolved DNS, cookie config and authentication. I am yet to see practical values that we may gain due to the differences.I did a quick performance test to find how
WebClient
(sync calls), HttpClient
(sync and async) perform. and here are the results:Using same
HttpClient
instance for all the requests (min - max)WebClient sync: 8 ms - 167 ms
HttpClient sync: 3 ms - 7228 ms
HttpClient async: 985 - 10405 ms
HttpClient sync: 3 ms - 7228 ms
HttpClient async: 985 - 10405 ms
Using a new
HttpClient
for each request (min - max)WebClient sync: 4 ms - 297 ms
HttpClient sync: 3 ms - 7953 ms
HttpClient async: 1027 - 10834 ms
HttpClient sync: 3 ms - 7953 ms
HttpClient async: 1027 - 10834 ms
Code
My Questions
- The REST calls return in 3-4s which is acceptable. Calls to RESTservice are initiated in controller methods which gets invoked fromajax calls. To begin with, the calls run in a different thread anddoesn't block UI. So, can I just stick with sync calls?
- The above code was run in my localbox. In prod setup, DNS and proxylookup will be involved. Is there any advantage of using
HttpClient
overWebClient
? - Is
HttpClient
concurrency better thanWebClient
? From the test results, I seeWebClient
sync calls perform better. - Will
HttpClient
be a better design choice if we upgrade to .Net 4.5? Performance is the key design factor.
21.1k1010 gold badges120120 silver badges168168 bronze badges
user3092913user3092913
3 Answers
I live in both the F# and Web API worlds.
There's a lot of good stuff happening with Web API, especially in the form of message handlers for security, etc.
I know mine is only one opinion, but I would only recommend use of
HttpClient
for any future work. Perhaps there's some way to leverage some of the other pieces coming out of System.Net.Http
without using that assembly directly, but I cannot imagine how that would work at this time.Speaking of comparing these two
- HttpClient is more closer to HTTP than WebClient.
- HttpClient was not meant to be a complete replacement of Web Client, since there are things like report progress, custom URI scheme and making FTP calls that WebClient provides — but HttpClient doesn’t.
If you’re using .NET 4.5, please do use the async goodness with HttpClient that Microsoft provides to the developers. HttpClient is very symmetrical to the server side brethren of the HTTP those are HttpRequest and HttpResponse.
Update: 5 Reasons to use new HttpClient API:
- Strongly typed headers.
- Shared Caches, cookies and credentials
- Access to cookies and shared cookies
- Control over caching and shared cache.
- Inject your code module into the ASP.NET pipeline. Cleaner and modular code.
Reference
C# 5.0 Joseph Albahari
(Channel9 — Video Build 2013)
KyleMit60.4k3838 gold badges261261 silver badges423423 bronze badges
Anant DabhiAnant Dabhi11.1k44 gold badges3030 silver badges5252 bronze badges
HttpClient is the newer of the APIs and it has the benefits of
- has a good async programming model
- being worked on by Henrik F Nielson who is basically one of the inventors of HTTP, and he designed the API so it is easy for you to follow the HTTP standard, e.g. generating standards-compliant headers
- is in the .Net framework 4.5, so it has some guaranteed level of support for the forseeable future
- also has the xcopyable/portable-framework version of the library if you want to use it on other platforms - .Net 4.0, Windows Phone etc.
If you are writing a web service which is making REST calls to other web services, you should want to be using an async programming model for all your REST calls, so that you don't hit thread starvation. You probably also want to use the newest C# compiler which has async/await support.
Note: It isn't more performant AFAIK. It's probably somewhat similarly performant if you create a fair test.
Firstly, I am not an authority on WebClient vs. HttpClient, specifically. Secondly, from your comments above, it seems to suggest that WebClient is Sync ONLY whereas HttpClient is both.
I did a quick performance test to find how WebClient (Sync calls), HttpClient (Sync and Async) perform. and here are the results.
I see that as a huge difference when thinking for future, i.e. long running processes, responsive GUI, etc. (add to the benefit you suggest by framework 4.5 - which in my actual experience is hugely faster on IIS)
Owen Blacker3,22722 gold badges2929 silver badges6666 bronze badges
Anthony HorneAnthony Horne2,12222 gold badges2020 silver badges4646 bronze badges