GET method with list of paramethers as body or POST method?

Question

I need to create an endpoint which will provide a list of objects, I need to pass as request body list of ID's of objects I want to retrieve. As far I know this should be done by GET method since it's only retrieving the object and not modifying them, but when I want to call it from client side using RestTemplate, it does not have any method for GET to pass body. However, this is achievable with POST method. Should I use POST instead of GET or is there another solution?

EDIT: for everyone with the simmilar problem, this thread helps a lot:

HTTP GET with request body

Answer 1

If you want to stick to GET which is semantically more correct you need to pass the list of IDs as a Request parameter instead of body because GET doesn't define a body.

Using POST in which case you can pass the list in the body, is generally fine also though some sticklers will state that it isn't semantically correct.

Note that POST is sometimes preferred depending how complex or long the query data is.

Answer 2

RFC 7231

A payload within a GET request message has no defined semantics; sending a payload body on a GET request might cause some existing implementations to reject the request.

That eliminates GET as an option; HTTP simply doesn't support what you want to do.

i need to pass as request body list of ID's of objects i want to retrieve.

GraphQL is gaining some traction as a querying language for web apis. It's the same sort of problem; a complicated query. Github, for instance, is implementing a graphQL endpoint that supports the POST method.

This does produce an api that is more RPC than REST. So it goes.

The point, as this applies to your problem, is that query via POST as a pattern does exist as a pattern.

is there other solution?

There are some alternative designs that might serve you better

How does a web page load multiple images? One at a time. An advantage to this approach is caching - the web page can re-use the representation of the images it has seen before. This affords some of the improved scaling promised by the REST architectural constraints.

Compare this with asking for a representation of a list of objects, where the representation necessarily changes each time you change the items in the list, or each time any individual item changes its representation.

You can use the ids themselves as part of the URI, which is to say that if what you want is a representation of a list of objects, then perhaps the list of objects is its own concept (resource) with its own identifier.

This approach might manifest in one of two ways. You might might keep the list of ids explicit (making the concept itself implicit), in other words, by enumerating the ids in the URI itself.

Alternatively, you might try making the concept explicit in your design - figure out why the client is asking for that particular combination of ids, and create a resource that represents that concept. For example: if the client is picking the ids because they have some property in common (all open tickets), then the concept is a collection filtering on that property -- so you would create an open ticket resource.

Similarly, if the list of ids comes about because the client is paging through results, then you can make the paging explicit (this approach is common with feeds, see AtomSyndication).

In short, you may be having trouble finding a good answer for REST because you have the wrong problem.