Java：做静态HTTP请求是一种好习惯吗？

Question

I just had a discussion with a colleague who asked me why i would do a static Http request like this:

HttpClient.doGet(HashMap<String,String> Parameters);

instead of invoking an object of the class via default constructor and use a nonstatic method like this:

new HttpClient().doGet(HashMap<String,String> Parameters)

If assuming that the implementation of the method doGet only uses the parameters of the function without any member variables, would the static implementation be problematic in any way, eg thread safety?

Answer 1

It depends on what you mean by problematic, but going off just your given example, the answer is no, the static method call is not problematic, and is arguably better, since no object needs to be instantiated.

You mentioned thread safety, so I will touch on that. You only need to be concered with thread safety if there is "mutable shared state" involved. Mutable being the key-word here. For example, if multiple threads were sharing the same instance of HttpClient, and that HttpClient was keeping track of some state by mutating one or more of its member variables, then that definitely has the potential to be problematic.

Answer 2

... but also, every HTTP request has to go out on a network, to a physical computer someplace else, then to return, "at least many milli- seconds later." So, there's really no point in "multi-threading" that chore. A single thread can be given the responsibility for sending out parallel I/O-requests to the remote hosts, receiving requests from the rest of your code by means of some thread-safe queue and returning the responses in like manner on another queue (or, queues).

It is wasteful to associate "a thread" with "a request." A very small pool of workers can be consuming the responses that come off of that reply-queue.

(And of course, there are plenty of existing Java open-source frameworks that implement all of this very-familiar plumbing for you.)