Post History

**tl;dr** Just use a POST. There's likely literally no reason not to in your situation.

1. REST is not a standard.
2. Being RESTful in and of itself is not a virtue.
3. I strongly suspect that your current code/API design violates the guidelines of REST more often than it follows them so there's little reason to be "puritanical" here.
4. It also seems pretty clear that your use-case isn't the situation REST was designed for.

REST was designed for handling long-lived, large^["Large" here means like tens of kilobytes or more in contrast to fine-grained AJAX requests which might pull back only hundreds of bytes of payload.] slowly changing hypermedia documents shared between different organization domains, e.g. different companies. From the details you given and just base rates, I suspect this isn't the situation you're in so there's no reason to expect REST to be an appropriate pattern for your use-case. This isn't to say that there aren't ideas in REST that would be useful for you, but you need to evaluate them for your use-case, and you certainly should not feel remotely constrained to adhering to REST guidelines.

Instead, you "just" need to think about the needs of your application and the engineering costs of various choices. You can frame this as an analysis of the motivations for REST's design choices and how they apply to your particular situation, or you can just do it from first principles. For reasons, I'll take the former approach though there is absolutely no reason to anchor your thinking to REST for this.

From a REST perspective, the main motivation to use GET is that it communicates that a document can be cached. I suspect you aren't doing any HTTP level caching of these requests and likely would actively not want that. Also, with such selective filters, (long-term) HTTP-level caching may not be that effective anyway.

Another important aspect of GET from a REST perspective is that GET is assumed to be safe repeat, i.e. it a GET request has no (significant) side-effects. A POST request does not suggest that guarantee^[Of course, using GET doesn't *ensure* this either.]. This makes retrying and prefetching easier and more natural. In your situation, your SPA knows the semantics of the endpoints its making requests to so this isn't an issue.

While not really a GET/POST distinction but rather a URL parameters/request body one, one benefit of having URL parameters is that it allows you to easily bookmark pages. This doesn't seem relevant in your circumstances as it sounds like these URLs are never in the browser's address bar and in some cases this isn't even being accessed by a browser. There are also other ways to accomplish this flow if it was desired that may be better (or worse), e.g. providing the ability to "save a query" as an application-level feature.

There are potentially other concerns that could be considered, but ultimately I suspect that there aren't any compelling and *applicable* benefits to using a GET request here. Even from a REST perspective using a POST when you could use a GET is at worst "sub-optimal" rather than "incorrect". There are some potentially compelling reasons to prefer a POST here.

What I would do based on my guess at your situation is likely to switch to a POST request and pass the parameters in the body. In fact, I'd most likely have written it that way in the first place as I don't like passing significantly structured data as URL parameters. That said, if I was reasonably confident that the GET approach would be unlikely to cause problems, I could switch to the POST approach quickly, and that my "customers" wouldn't be too annoyed if I was wrong about it being a problem, I would probably not have making the change to POST be a high priority. Basically, switching to POST now means you can stop worrying about it, but you also probably have more important things you could be doing so...

I would strongly avoid any solution that required changing server configurations or, like a body in a GET request, may get mishandled by some web server or other piece of infrastructure. It's extremely hard in most setups to maintain a connection between the motivation for server configuration and code that depends on that server configuration. This leads to either the server configuration change being undone by someone who doesn't know better or upgrades or redeployments, and/or to sub-optimal server configurations to support code no longer exists.