Async is an important category that deserves better coverage. Fundamentally, REST and the alternatives (SOAP, etc.) are all RPC protocols. They may make use of the RPC nature of HTTP or maybe like XML-RPC they shove another RPC layer on top. A remote procedure call sounds like the simplest component of a remote api, but it is not. In RPC you make a request and wait for a reply.
But with async, you send a message and that is it. This can be implemented on top of HTTP RPC such as with Websockets, but the HTTP layer is unnecessary. Messaging using the AMQP protocol is a nice alternative. You can open a socket and hold it open for sending and receiving messages. When you send a message, it can be received by an MQ broker like RabbitMQ for guaranteed delivery to whatever internal service(s) need to process it. And when some kind of result needs to be sent back to the message originator, the socket is open and ready to receive it. For those things where the app needs RPC, it is simple to send a message and wait for a reply message. But when all you need is a notification going out, or coming in, that works too.
While MQTT and ZeroMQ and others could be used, it would be nicer if the Internet standardized on AMQP at a known port (just like HTTP) and even included the use of an MQ broker with all the optional services (topic queues, persistence, guaranteed delivery) that can be provided.
For lower volume "push" data, it would be nice if there were a convention in REST for how to request a subscription in which you provided the callback URL where the updates would be PUT.
Not that this scales as well as message service "topics" (with multiple subscribers/listeners), but it's a start, and doesn't sound much worse than the load for point-to-point queues.
But with async, you send a message and that is it. This can be implemented on top of HTTP RPC such as with Websockets, but the HTTP layer is unnecessary. Messaging using the AMQP protocol is a nice alternative. You can open a socket and hold it open for sending and receiving messages. When you send a message, it can be received by an MQ broker like RabbitMQ for guaranteed delivery to whatever internal service(s) need to process it. And when some kind of result needs to be sent back to the message originator, the socket is open and ready to receive it. For those things where the app needs RPC, it is simple to send a message and wait for a reply message. But when all you need is a notification going out, or coming in, that works too.
While MQTT and ZeroMQ and others could be used, it would be nicer if the Internet standardized on AMQP at a known port (just like HTTP) and even included the use of an MQ broker with all the optional services (topic queues, persistence, guaranteed delivery) that can be provided.