Hi team,
I have an inbound GET request like this
example.com?name=abc&id=123&age=29
I need to set the target url to the following
example2.com/abc/123/29
in the inbound request, some query parameters are mandatory, some can be empty so its a bit tricky to set the target url
I can use one JS policy with if/else conditions to set the target url OR I can use multiple(could be 3 or 4) conditional Assign Message policies to achieve the same.
if request.queryparam.name!=null, use one Assign message policy OR if request.queryparam.name== null, use another Assign message policy and so on...
Which is more efficient and which approach should I take?
Thanks
Is there some consistent order to the URL path eg /name/id/age? or do you expect to just use the order of the request query parameters because client could send these in different order each time ..
I would not prioritize "performance". Instead focus on readability and maintainability.
You can use AssignMessage to accomplish what you want, maybe in a single policy. For example, if the name and id queryparams are optional, you can do this:
<AssignMessage name='AM-Target-URL'>
<AssignVariable>
<Name>segment1</Name>
<Ref>request.queryparam.name</Ref>
<Value>default-name</Value> <!-- fallback -->
</AssignVariable>
<AssignVariable>
<Name>segment2</Name>
<Ref>request.queryparam.id</Ref>
<Value>default-for-segment2</Value>
</AssignVariable>
<AssignVariable>
<Name>target.url</Name>
<Template>/{segment1}/{segment2}</Template>
</AssignVariable>
</AssignMessage>
This feels pretty readable to me.
But it's a simple case. If the situation is more complicated, for example if there is some mapping between the qparam and the deisired path segment, then, a JavaScript policy with a lookup table might be more readable. Eg if the name qparam is "abc" then the pathsegment should be "xyz". In that case i might want to use JavaScript, with maybe some constants defined in a properties file.