Suggestion: Warn or fail when GET method in @FeignClient has unannotated parameters

[dkswnkk]

Summary

This issue is related to the unexpected behavior where a GET method in @FeignClient silently becomes a POST if its parameters are not annotated (e.g., missing @RequestParam or @SpringQueryMap).

I previously documented the full behavior and reasoning in an issue in the core Feign repository:
OpenFeign/feign#2872

Clarification

I’ve seen related discussions such as #832, which suggests workarounds like switching the HTTP client to Apache HC5, or adding @SpringQueryMap. That may solve specific symptoms, but my suggestion is preventive and aimed at improving developer experience.

Proposal

when a GET method contains one or more parameters without annotations like @RequestParam, @PathVariable, @SpringQueryMap, etc., it would be very helpful to:

• Emit a warning during startup (default behavior), or
• Optionally fail fast, via a configurable flag (e.g., failOnUnannotatedGetParams = true)

This could save developers hours of debugging, especially since:

• Feign logs the request as a GET on the client side,
• But the server actually receives a POST request due to how HttpURLConnection or other HTTP clients behave with GET + body,
• And the request body is silently empty (Content-Length: 0), which causes confusing behavior on the receiving end.

On the sending side, application logs indicate that a GET request was made, but on the receiving side, the request is logged and handled as a POST.
This mismatch makes the issue especially difficult to detect and diagnose.

Why I'm Opening This Issue Here

Although I originally opened this issue in the core OpenFeign/feign#2872, I later looked into where this behavior might originate.

While I’m not 100% certain, it appears that the logic responsible for interpreting annotations like @RequestParam and deciding how parameters are bound resides in SpringMvcContract.java, which is part of the spring-cloud-openfeign project — not the core Feign module.

So I’m opening this issue here as well, in case this is indeed the correct place to address the problem.

[OlgaMaciaszek]

Hello @dkswnkk, thanks for reporting the issue. As this project is now in maintenance mode, we only handle dependency upgrades, security issues and bugs. However, feel free to provide a pull request with this change - we'll review it.

[dkswnkk]

Hi @OlgaMaciaszek, I’ve opened a PR for this — appreciate your consideration when convenient.
Thanks again!

Also, I just realized the project is in maintenance mode while looking into the issue — thanks for still being open to contributions 😅