This is also something I think about. It seems that this approach is slowly getting out of fashion and people are starting to prefer APIs similar to SOAP (but J

This is also something I think about. It seems that this approach is slowly getting out of fashion and people are starting to prefer APIs similar to SOAP (but JSON based instead of XML). However if it is a HTTP based API, I'd still think it should be exposed in a way to use HTTP methods correctly. As they align quite well with what web applications will mostly do (CRUD operations). If you need to do some extra operation, you could create a resource which wraps that operation, for example triggerScheduledJob could be POST /scheduled-job-triggers with body describing parameters to triggerScheduledJob method. Another approach seems to be to use protocol buffers and something like gRPC. This is good for command line tools or internal communication between services but still, public API exposed over HTTP protocol should probably be designed to accommodate HTTP verbs.