Everything becomes easier if you could change your backend servers to support /liveliness1 and /liveliness2 or something, something that makes them unique. Then you could use different topic subscriptions on different queues that connect to different RDPs with different REST Consumers, with each one pointing to either server1 or server2. This way, the client would dictate which server it wants by specifying a different target.
Either that, or you’ll have to use different Message VPNs, with different REST ports exposed, and VPN1 has an RDP that points to server1, and VPN2 has an RDP that points to server2. This way, the client would dictate which server it wants by specifying a different port.
One other option, mentioned by one of the Solace R&D engineers, is to use an HTTP proxy after the Solace RDP and before the various backend services. If the client making the GET can use an absolute path for the target (e.g. http://backendA/liveliness instead of just /liveliness ), the Solace broker will pass that straight through the RDP, and the proxy can then use some logic on the target to determine which server to send the request to. This does require the use of a proxy, but could be another option to consider…?