Microservices: REST vs Messaging

Question

I heard that Amazon uses HTTP for its microservice architecture. An alternative is to use a messaging system such as RabbitMQ or Solace. I personally have experience with the Solace microservice architecture, but never with REST.
Any idea what to use different big league options like Amazon, Netflix, UK Gov etc.? Another aspect is that the following things are required in microservices (among others):
* Pattern comparison
* Asynchronous messaging .. the receiving system may not be available * Publish a subscription * Cache load event .. that is, when the service starts, it may need to download all the data from several other services and should be notified when the data is fully loaded so that it can "know" that he is now ready for service
These aspects are, of course, handled by messages, not REST. Why should someone use REST (other than the public API). Thanks.

Answer 1

The standard that I used in the past is the use of web services when speed is the key requirement (and data loss is not critical) and messaging is where reliability is the key requirement. As you said, if the receiving system is not working, the message will be queued until the system returns to process it. If this is a REST endpoint and it disappears, the requests will simply fail.

Answer 2

The REST API assumes the use of HTTP only. It is completely stone age technology and does not accept async. messaging. For messaging with plugins I would consider WebSockets Gateways - sorry for the fake claims