Request-response
Request-response messaging, is a mechanism to send messages asynchronously between Diffusion clients. You can use it to implement application services.
A client can send a message to multiple clients. A client which receives a message can respond to it.
A request-response message can be sent to any of the following:
-
a particular client session
-
a group of client sessions
-
all clients that have registered a handler for a message path
|
Request-response is a entirely separate mechanism from pub-sub topic streaming. In request-response, sending messages does not affect topic values. |
Request-response messages have a data type (such as JSON or binary), like topics do. A response does not have to be the same type as the initial message.
Why use request-response?
Some examples of when you would use request-response messaging are given below.
One-off operations
Request-response messaging is useful for one-off operations where there is no need for an ongoing stream of data.
Examples:
-
An end user placing a bet
-
Updating the status of an order
Anything you might use a REST or RPC call for, can be done with request-response.
The higher efficiency and two-way nature of request-response makes it easier to use than REST.
Broadcast
Request-response can be used when you need to broadcast a message to a group of clients.
Examples:
-
Showing a special offer to a set of end users
-
Alerting clients that a service is about to be restarted
Co-ordination
Request-response can be useful for co-ordination within your application.
Examples:
-
A client reporting it has entered a certain state
-
A 'concierge' pattern - instead of subscribing to topics directly, the client sends a request-response message requesting data, and a control client grants a subscription to the most appropriate topic, or denies the request.