Rewrite URL Path - RDP Rest Consumer
Is it possible to rewrite the URLs before sending the request to the Rest Consumer using solace RDP?
For example:
https://192.168.5.111:9443/api/deleteResult -> http://192.168.7.111:7001/test/deleteResult?
Comments
-
Hey @dreamoka ! There is a Solace PubSub+ feature you can leverage to dynamically change the URL; check out the Substitution Expression section in the docs. You can also check out @Aaron's office hours where he talks about this in details here
Basically under the queue binding settings, you can change the "Request Target Evaluation" to substitution expression and in the "Post Request Target" you can leverage the expressions defined in the docs to customize the end point.
Hopefully this answers your questions and give you some hints on the powers of RDP
0 -
Here's a shorter, less-rambling video where I show how to configure substitution expressions on RDPs: https://youtu.be/INMrSL2fA3E?t=125 😬
Note that this feature only works for REST Messaging mode, not REST Gateway mode. 👍🏼
0 -
Hi @Aaron and @Tamimi thank you so much. I need to use REST Gateway mode.
The reasons are :
1) Need to provide connectivity between a RESTful service endpoint and a REST client.
2) Need to support HTTP REST Method : GET, PUT, DELETE and POST
May I know how to configure in the solace message broker if there are two same REST endpoint? Example, http://rest1/liveliness (get method) and http://rest2/liveliness (get method)
0 -
Yeah, if you need to support lots of HTTP methods, you need to use Gateway mode.
In Gateway mode, you cannot re-write the URL. Whatever comes in goes out. Modifying the POST Request Target only works in Messaging mode:
solace1040(...est/rest-delivery-point/queue-binding)# post-request-target ? COMMAND: post-request-target <post-request-target> no post-request-target DESCRIPTION: The request-target string to use when sending requests. It identifies the target resource on the far-end REST Consumer upon which to apply the request. There are generally two common forms for the request-target. The origin-form is most often used in practice and contains the path and query components of the target URI. If the path component is empty then the client must generally send a "/" as the path. When making a request to a proxy, most often the absolute-form is required. This configuration is only applicable when the Message VPN is <---- in REST messaging mode. <---- The no version of the command returns its value to the default ("").For your second, you want to configure the broker to send two GET requests to two different REST servers? From a single "incoming" GET? Essentially, pub/sub for REST? This would introduce a race condition, both backend servers would attempt to reply to the GET, and the broker will only return the first one that responds and discards the 2nd one. Is this the behaviour that you want? If not, can you more fully explain your desired setup and behaviour?
0 -
Yeah. I have no choice.
For my second question, I wonder whether message broker has rewrite URL path feature.
For example, when REST requester send API GET request (http://broker/A/getLiveliness), the message broker will rewrite the destination URL path (http://BackendServerA/getLiveliness) and send to Backend Server. Definitely, I don't want to create race condition situation. But there will be chance two different REST servers having same rest endpoint.
0 -
@dreamoka ok, I think I get it. Let me rephrase and you tell me if I'm correct:
You need to use Gateway mode to support (almost) any HTTP verb. Since using Gateway mode, we don't have the option of rewriting the outbound URL target. And you have a situation where you have two backend rest servers (A and B), each providing a service on
/getLiveliness. And you're wondering how you can design/configure the broker such that there is some way for clients to send a request to a particular backend server.Off the top of my head, I don't know. I'll think about it for a bit. Perhaps others here might know? But I'll just ask: are you sure you can't use POST for everything? It would simplify a lot of things. haha
EDIT: If you're just looking to round-robin the incoming request to either server, that's definitely possible... you just need to configure two REST Consumers in your RDP.
0 -
@dreamoka Thinking on this further: what exactly are you trying to do, or what is the benefit of going through Solace? In Gateway mode, the broker acts as (mostly) a transparent proxy. What benefit is it to have your client request through the broker, rather than just requesting from the specific backend service it wants?
1 -
Everything becomes easier if you could change your backend servers to support
/liveliness1and/liveliness2or 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
GETcan use an absolute path for the target (e.g.http://backendA/livelinessinstead 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..?1
