On PubSub+ Broker HTTP/REST is used in “Fire and Forget”/async mode, it’s a one way communication protocol only. So you can’t do Request/REPLY over HTTP/REST
REST Can be used in two ways with Solace :
- HTTP POST on host:port/TOPIC/ YourTopic , your http client will only receive an empty response with HTTP 200
- RDP (REST Delivery Point), it’s Solace name for webhook. It’s a Solace Queue with subscriptions to one to many topics the messages that are capture by the queue are send as HTTP POST to an endpoint that you define. Host/port and URI are configurable. You can use the message topic level to build the HTTP REST URI
- With HTTP you can only sent one message and wait for the HTTP 200. It’s not a connected protocol such a Solace SMF or AMQP/MQTT. Those connected protocol can ACK multiple message at a time, which give better throughput even with high latency link
- HTTP should be considered when there’s no other available option. It’s not a protocol well suited for messaging, while SMF, AMQP or MQTT are.
Example : if you’re coding in PHP for example, where’s there’s no Daemon running all the time, you could HTTP POST to solace an event, have some microservices processing the event and use RDP to get the processing result back as an HTTP POST sent to your PHP server using RDP.
AMQP Request Reply : a queue is dynamically provided so that your requester get the reply.
Check this tutorial :
AMQP link is bidirectionnal.
Is it amqp request-reply consider async ?
I would say no, since you’re client is blocked until you’ll get the response.
But the other side, the code that process the request and produce the reply, it can be async, scale up and down, use the benefit of the broker for guaranteed messaging (no message loss), Partitioned Queue to ensure messages are processed “in order” while being able to scale the number of microservice processing the requets