Thank you Sven. I'll go with instantiating a new client for each request, the less state shared, the better :-)
Regards! Esteban A. Maringolo On Fri, Oct 29, 2021 at 12:15 PM Sven Van Caekenberghe <s...@stfx.eu> wrote: > Hi, > > > On 29 Oct 2021, at 15:42, Esteban Maringolo <emaring...@gmail.com> > wrote: > > > > Hi, > > > > I happened to me more than once that I have to create some REST service > "client" in which I usually wrap an HTTP client inside (ZnClient in this > case), and all the calls to the service, end up using the HTTP client, > inside some mutex to serialize the execution. > > Yes, that is a good design. However, whether your REST client object > wrapping a ZnClient is used by multiple concurrent threads is another > decision. I would personally not do that. See further. > > > But I don't like that, in particular when some endpoints are better with > streaming responses (large downloads) and I have to fiddle with the client > and set it back to the settings before executing the request. > > You only can and should reuse connections to the same endpoint/service > only, doing similar types of request/responses (let's say simple ones). > > A definitive danger point is authentication and authorization: different > calls by different users might need different REST call settings, each > time. Also, caching can be a problem, if user A can see / sees the cache of > user B. > > > So, long story short... is it always safer to instantiate a new ZnClient > on a per request basis since no state is shared, but I guess it is also > less effective if I'm performing several requests to the same server. > > A new instance is definitely safer because it is cleaner. Reusing a > connection is more efficient when doing multiple calls in (quick) > succession. The penalty is usually pretty low, you can postpone optimising > until there is an actual problem. > > Error handling and recovery are also harder in the reuse case (what state > is the connection in ?). > > ZnClient does a form of automatic reconnection/retry though. > > > What are the recommended approaches here? > > > > > > Esteban A. Maringolo > > HTH, > > Sven >
