Would you use HTTP QUERY for complex searches?

The main appeal is clearer semantics. A request can carry a substantial filter or query without putting it all in the URL, while still being defined as retrieval rather than a state-changing action. That seems useful for new APIs with genuinely complex searches.

I would not assume it works everywhere just because the application framework accepts a custom method. Check the whole request path, including gateways, proxies, security filters, and monitoring. A component that rejects or mishandles an unfamiliar method can make the rollout confusing.

For an existing search endpoint, I would leave it alone unless there is a concrete problem with the current design. Changing the method means updating clients and infrastructure, and a working POST-based search may not gain enough to justify that work.

For a new API, it is worth considering if request parameters are too complex or lengthy for a URL. The method itself does not make an endpoint automatically cacheable. Caches still need to support the method and handle the request body correctly.

One small caution: moving filters into a body can keep them out of URLs, browser history, and some URL-focused logs, but it is not a privacy feature by itself. Request bodies can also be recorded, so sensitive values still need careful handling across the application and its infrastructure.

I would treat it as an API design option, not a shortcut around logging, access control, or transport security.