-
Notifications
You must be signed in to change notification settings - Fork 812
Description
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.