I would not be so religious in preaching REST rules.
REST is fine, except that it stumbles in real world problems that make some its conventions inconvenient, to the point you realized that you should not follow them.
For instance, there are much more types of actions that the limited number of HTTP methods can accomodate.
Lets say you have an API call that can preview how certain data will be rendered. That API call does not alter data, so POST, PUT, DELETE and PATCH are not appropriate. You are left with GET, which makes sense because you are retrieving data.
The problem of using GET is that parameters are passed via URL. This is fine for parameters with a limited size. However, if you want to pass parameters that exceed the limits of URL of certain Web servers and proxies, the URL may get truncated. So, GET is not adequate. You would not to switch to POST because you would not have such a low parameter length limit.
Another aspect is the problems of firewalls or proxies that block any type of requests except GET and POST. So if you need to access an API that requires PUT, DELETE, PATCH, or whatever, those HTTP methods are inadequate.
It is not by coincidence that browser based Web applications only use GET or POST.
In sum, REST is fine as a set of conventions, but if you do not follow its conventions, it is fine because that you need to adapt to the constraints of the real world.