Search requests with multiple search values

Question

(related: Fetching records matching multiple joined attributes)

If Spring Data doesn't allow GET requests to have a body (and it's considered bad practice anyway)

curl -X 'GET' \
  'http://localhost:8080/api/user' \
  -H 'accept: */*' \
  -H 'Content-Type: application/json' \
  -d '{
  "email": "steve@yahoo.com"
}'

TypeError: Failed to execute 'fetch' on 'Window': Request with GET/HEAD method cannot have body.

    @GetMapping
    public ResponseEntity<List<UserResponseDto>> findUsers(@RequestBody FindUserRequestDto userRequestDto) {
        List<UserResponseDto> userResponseDtos = userService.find(userRequestDto);
        return ResponseEntity.ok(userResponseDtos);
    }

import lombok.Getter;
import lombok.Setter;
import java.time.LocalDate;
@Getter
@Setter
public class FindUserRequestDto {
private LocalDate dateOfBirth;
private String phone;
private String name;
private String email;
private int pageNumber;
private int pageSize;

}

then how am I expected to pass all that data? Am I supposed to pass all those as request parameters? But it would make the controller method's parameter list bloated and ugly. In a production scenario, a DB entity can easily have dozens of attributes (even if they should be refactored away).

Semantically, it's clearly not a POST.

What am I expected to do in this case according to REST conventions? Were REST conventions ever formalized, to begin with?

score 4 · Answer 1 · answered May 25 '25 at 11:53

were REST conventions ever formalized, to begin with?

No. It's just a rough idea people have run with. Frankly if I knew you could get a doctorate for this kind of thing I would have stayed in academia.

You can only understand the popularity of REST if you were forced to do SOAP and similar protocols in the past. They were clunky and you had to read manuals to make them and work with them. With REST you just browsed to the URL and got your result.

Obviously the answer to your question is the same as your other questions ie. "For god's sake just use POST and forget about being RESTful"

No-one bothers with being fully RESTful with all the HATEOAS stuff anyway.

Arseni Mourzenko · Accepted Answer · 2025-05-27T17:07:42.623

HTTP GET with a request body? Not a good idea. Even if you can do that, it doesn't mean that you should, because:

It makes your API more cryptic and goes against POLA.
Things may get very ugly at some point, especially at infrastructure level.

One scenario I can think of is some caching at the level of a proxy or a reverse proxy. At some point, one user search will receive cached data from another search, and you'll spend hours trying to desperately understand what's happening, since the behavior is not necessarily straightforward to reproduce.

Another painful thing may happen when you'll migrate your API. Say you move it to the cloud (or to a different cloud), and suddenly, it starts misbehaving, and you need to stop putting data in HTTP GET request body, which also means that you need now to patch all the clients as well.

So:

Either pass the search options in the URI.
Or go for a POST.
Or use your own HTTP request method, such as SEARCH, for which you are the one who dictates how exactly it should be used.

JimmyJames supports Canada · Answer 3 · 2025-05-28T13:24:44.167

It is a bad idea to pass a body with a GET. A lot of tooling won't allow it and as mentioned in other answers, it can cause caching issues.

If you don't want to pass the parameters on the URI (either as path or query parameters) but want to stick with GET, you can pass parameters as header parameters. This is not terribly common but not outside of spec. It's usually used to avoid passing sensitive data on URIs (because they end up in access logs.) I'm unsure of how well this is supported by caching layers in general, though. On a side note, email addresses are considered to be sensitive data in some contexts.

Otherwise, you are going to have to go with POST. One pattern that comes up a lot is to have a POST call which takes in parameters and returns a GET URI for the data. You still need to make an initial POST call, of course, but the returned URI can be reused, if that's a concern.

Search requests with multiple search values

3 Answers3