Spring's @FeignClient automatically converts GET request with json body to POST

[Al Matevski]

Hello all, this is my first post here, so please forgive me and point me to right directions  if I make some rookie mistakes

In my work, we use feign clients, and we have some external API that exposes GET request that receives the data needed to filter on in a json body.
So no queryparameters, just json body.

And here is a code sample of the client

@FeignClient
public interface SomeClient {

  @GetMapping("/someEndpoint", consumes = MediaType.APPLICATION_JSON_VALUE, produces = MediaType.APPLICATION_JSON_VALUE)
  SomeResponse get(@RequstBody SomeRequest request)
}

After some struggling, I found that feign client converts the request into a POST request.

What is even stranger is that the logs reported that the client is makign GET request, while technically it was making POST request.

The solution was to replace the client with some other client like RestClient or WebClient.

My question to you is, what do you think of this behavior?

Personally, I don't find this behavior acceptable, because the technical specification of HTTP does not specifically forbid GET requests with body.

And requiring that GET should not have body is mostly a semantics, and not technical, especially for Machine-to-Machine communication,

But I understand  that there are technical behaviors and asumtions that the browsers make for GET requests.

I've also read this topic too, https://coderanch.com/t/781592/engineering/Http-POST and I found it very informative.

[Tim Holloway]

Welcome to the Ranch, Al!

I have no idea what a "feign client is. Possibly a mis-translation of "mock client"?

There are all sorts of apps that can send mock (test) client requests, programs like curl and Selenium, for example.

So we'll need more information before we can help you.

[Tim Holloway]

Oh never mind, I'm obviously going senile. You did say Spring @FeignClient.

[Tim Holloway]

OK, here's what it looks like.

You're using @GetMapping. First of all, that's for GET requests. For POST, you'd use @PostMapping.

Secondly, and more important, I think those annotations are for the SERVER, not the client!

The client should be using something like this:

    @RequestMapping(method = RequestMethod.POST, 
           value = "/stores/{storeId}", consumes = "application/json")
    Store update(@PathVariable("storeId") Long storeId, Store store);

[Stephan van Hulst]

This isn't strange at all.

GET requests don't have a body.

If you want to send a body with your request, it MUST use a method other than GET.

[Al Matevski]

Tim Holloway wrote:OK, here's what it looks like.

You're using @GetMapping. First of all, that's for GET requests. For POST, you'd use @PostMapping.

Secondly, and more important, I think those annotations are for the SERVER, not the client!

The client should be using something like this:

    @RequestMapping(method = RequestMethod.POST, 
           value = "/stores/{storeId}", consumes = "application/json")
    Store update(@PathVariable("storeId") Long storeId, Store store);

Thanks for the response, but I don't think this is the issue. Spring's @FeignClient work just fine with @GetMapping, Basically feign allow to specify clients using spring's annotations.

[Al Matevski]

Stephan van Hulst wrote:This isn't strange at all.

GET requests don't have a body.

If you want to send a body with your request, it MUST use a method other than GET.

I don't think it's a MUST, at least not on a technical level. Why the protocol doesn't cut the request body if it's a MUST that GET should not have a request body?

Imagine Postman, for example, not sending a GET request with a request body because, it's convention to not send a request body with GET.

Or worse, imagine Postman silently converting the GET request in a POST request. :mindblow:

I can't think of a single reason that a library for a http client must forbid to send GET request with a request body.

[Stephan van Hulst]

Al Matevski wrote:I don't think it's a MUST, at least not on a technical level. Why the protocol doesn't cut the request body if it's a MUST that GET should not have a request body?

The HTTP protocol DOES specify that GET requests MUST NOT include a message body.

Any client that includes a message body with a GET request is in violation of the HTTP protocol specification.

Imagine Postman, for example, not sending a GET request with a request body because, it's convention to not send a request body with GET.

I don't know whether or not Postman forces compliance with the HTTP protocol specification, but it's definitely not just convention. It's a hard requirement.

Or worse, imagine Postman silently converting the GET request in a POST request. :mindblow:

I agree that silently converting the request method is bad. The library you're using should have rejected the operation.

I can't think of a single reason that a library for a http client must forbid to send GET request with a request body.

Because the HTTP specification says that it MUST.

[Tim Holloway]

https://datatracker.ietf.org/doc/html/rfc7231#section-4.3.1

So a GET with a body isn't expressly forbidden.

IF you like to live dangerously.

Bear in mind also that just because the destination server would accept a GET with a payload doesn't mean that an intermediate stage (load balancer, firewall with packet inpection, etc.) might not have other ideas.

[Tim Holloway]

And, again, I think that you're using the wrong annotation for a client. I can find absolutely no examples of a FeignClient using @GetMapping, including in the Spring docs themselves. @GetMapping is a server annotation.

[Al Matevski]

Tim Holloway wrote:And, again, I think that you're using the wrong annotation for a client. I can find absolutely no examples of a FeignClient using @GetMapping, including in the Spring docs themselves. @GetMapping is a server annotation.

Can you please start brand new spring boot project with initializr, spring cloud openfeign and create a feign client with @GetMapping?

[Tim Holloway]

https://github.com/spring-cloud-samples/feign-eureka/blob/main/client/src/main/java/demo/HelloClientApplication.java

[Al Matevski]

Tim Holloway wrote:https://datatracker.ietf.org/doc/html/rfc7231#section-4.3.1

So a GET with a body isn't expressly forbidden.

IF you like to live dangerously.

Bear in mind also that just because the destination server would accept a GET with a payload doesn't mean that an intermediate stage (load balancer, firewall with packet inpection, etc.) might not have other ideas.

You are correct on this. On a protocol level specification, GET with  a body isn't forbidden, but some implementation might treatthe body differently since GET requests are subject to performance optimization.

But, even then, there is no excuse for any library for http client to either forbid me to send GET request with body or silently converting it to POST request.

At most, I would accept a fair warning in logs that tells the developers that it is not advised to send GET request with body.

Postman. CURL for example, do not forbid sending GET request with body.

[Al Matevski]

Tim Holloway wrote:https://github.com/spring-cloud-samples/feign-eureka/blob/main/client/src/main/java/demo/HelloClientApplication.java

I have a code on production that uses feign client with @GetMapping.

https://docs.spring.io/spring-cloud-openfeign/reference/spring-cloud-openfeign.html#netflix-feign-starter

Why are you so stubborn

[Tim Holloway]

Al Matevski wrote:
Why are you so stubborn

Because I happen to side with published docs rather than stuff that "just happens to work". Especially when you're telling me it doesn't work.

Even when stuff does "happen to work", it's not uncommon for it to suddenly stop working. And Myrphy's Law says that it will stop at the most inconvenient time possible.

As one of many examples, I almost ended up flying to Chicago at 2AM because an application programmer had written a sloppy compression algorithm, IBM pushed out an OS update that cleaned up how it handled pages in virtual memory and hundreds of production jobs immediately began crashing.

So given clear documentation or something that "works", I tend to favor the documentation.