Reusing rest client or not?

1,147 views
Skip to first unread message

Callum Evans

unread,
Jun 6, 2017, 3:58:35 AM6/6/17
to RestSharp
Just wondering if anyone can shed some light on the best-use practices for RestSharp.

We have a web API that needs to make a number of outbound requests to other APIs. We're using RestSharp to achieve this.

We're unsure if we should be reusing instances of the RestClient across the whole application, or if it's okay to create new rest clients each time we need to do a request? 

Currently, we use DI to inject a new instance each time one is needed, but we think this might be causing us some issues to do with ports being hogged etc. (http://www.westerndevs.com/Deployment/httpclientwrong/)

We've come across some discussions regarding HttpClient, and how reusing one instance is the go-to. Does anyone know if the same applies to RestSharp?

Cheers!
Callum,

Alexey Zimarev

unread,
Sep 5, 2017, 3:04:29 PM9/5/17
to RestSharp
I have seen a quesiton on GitHub if RestSharp client is thread safe and the conclusion was that it is not. Therefore, you are doing it like you should. Unless the client will be refactored towards thread safety, you will not be able to reuse it, when there is a risk of two parallel calls being made at the same time.

I have read the article and whilst I generally agree that HttpClient as a thread safe object, can be used for a longer time, the same can apply to things like SqlConnection. You can also reuse it. But you really shouldn't. It is so often made mistake that RavenDb people made a choice of limiting the number of request their session can make during its lifecycle. The article author mention that they intensively use http to communicate between "microservices", after "breaking the monolith". Well, I am quite sure they just built what is called "distributed monolith", replacing in-process calls by distributed calls, won nothing except headaches and all fallacies of distributed computing coming to them at night. If your "microservices" communicate with each other like hell, all over http, you need to reconsider your design.
Reply all
Reply to author
Forward
0 new messages