Vfrdtyky

I am in a situation where in I want to REST GET only the objects that I require by addressing them with one of the parameters that I know about those objects.

E.g., I want to GET all the USERS in my system with ids 111, 222, 333.

And the list can be bigger, so I don't think it is best way to append the URL with what is required, but use payload with json.

But I am skeptical using JSON payload in a GET request.

Please suggest a better practice in the REST world.

I am skeptical using JSON payload in a GET request.

Your skepticism is warranted; here's what the HTTP specification has to say about GET

A payload within a GET request message has no defined semantics

Trying to leverage Undefined Behavior is a Bad Idea.

Please suggest a better practice in the REST world.

The important thing to recognize is that URI are identifiers; the fact that we sometimes use human readable identifiers (aka hackable URI) is a convenience, not a requirement.

So instead of a list of system ids, the URI could just as easily be a hash digest of the list of system ids (which is probably going to be unique).

So your client request would be, perhaps

GET /ea3279f1d71ee1e99249c555f3f8a8a8f50cd2b724bb7c1d04733d43d734755b

Of course, the hash isn't reversible - if there isn't already agreement on what that URI means, then we're stuck. So somewhere in the protocol, we're going to need to make a request to the server that includes the list, so that the server can store it. "Store" is a big hint that we're going to need an unsafe method. The two candidates I would expect to see here are POST or PUT.

A way of thinking about what is going on is that you have a single resource with two different representations - the "query" representation and the "response" representation. With PUT and POST, you are delivering to the server the query representation, with GET you are retrieving the response representation (for an analog, consider HTML forms - we POST application/x-www-form-urlencoded representations to the server, but the representations we GET are usually friendlier).

Allowing the client to calculate a URI on its own and send a message to it is a little bit RPC-ish. What you normally do in a REST API is document a protocol with a known starting place (aka a bookmark) and a sequence of links to follow.

(Note: many things are labeled "REST API" that, well, aren't. If it doesn't feel like a human being navigating a web site using a browser, it probably isn't "REST". Which is fine; not everything has to be.)

But I believe POST or PUT are for some requests that modify the data. Is it a good idea to use query requests with them ?

No, it isn't... but they are perfect for creating new resources. Then you can make safe GET calls to get the current representation of the resource.

REST (and of course HTTP) are optimized for the common case of the web: large grain hypermedia, caching, all that good stuff. Various use cases suffer for that, one of which is the case of a transient message with safe semantics and a payload.

TL;DR: if you don't have one of the use cases that HTTP is designed for, use POST -- and come to terms with the fact that you aren't really leveraging the full power of HTTP. Or use a different application - you don't have to use HTTP if its a bad fit.