RabbitMQ has an RPC message option. The real advantage is that the workers can decide when to process the next message, which can balance load more evenly. With typical REST, you need a load balancer in front, which may not distribute requests where the most availability is, but as evenly as possible.
An advantage of HTTP+REST, is that you can fragment, and reverse-proxy portions of your public-facing, or rear-facing APIs as a whole, instead of as the fragmented parts they may be. You can otherwise break up your API based on features (or data fragments) over more monolithic approaches.
That said, look at your real needs, and only implement and add these kinds of complexity when you really need them.