Query string policy: Manipulate request URI query string

[mikz]

Use Cases

• Map URL /{orderId}/{accountId}/{incFields} into /sales-order/svc/v2/testDoc/{orderId}?account={accountId}&incFields={incFields}. This should work when request URL contains account or incFields parameters in the query string. ("Rewrite URL captures" policy #827)
• Match URL containing foo=bar in the query string and replace it by foo=daz. (URL rewriting policy: Allow to modify query parameters #724)

Details

This policy should parse URL query string and operate on individual arguments instead of using regular expressions. It should offer similar interface to the Headers policy: add,set,push - possibly even more as we expand use cases.

Considerations

Query params should be templated in similar way of the Headers proposal: #708

[davidor]

The part of modifying query parameters in the URL rewriting policy with push/add/set/delete commands has been done in #724

The other kind of transformation mentioned in the issue: Map URL /{orderId}/{accountId}/{incFields} into /sales-order/svc/v2/testDoc/{orderId}?account={accountId}&incFields={incFields}. has not been implemented yet.

[davidor]

Regarding the first use case mentioned in the issue:

I think we can also include it in the URL rewriting policy. In this policy, we already have 2 types of commands: one that replaces part of the URL by applying regex matching, and other that allows us to add/modify/delete query arguments.

I think we could add a third one for named arguments. This new command would just need 2 properties: match and replace. In your example, match = /{orderId}/{accountId}/{incFields} and replace = /sales-order/svc/v2/testDoc/{orderId}?account={accountId}&incFields={incFields}.

Regarding the implementation, I think it shouldn't be too hard. We can probably reuse some of the code that we already have for the 2 commands that we support.

[davidor]

There's an aspect that might complicate things a bit.

Right now, we have 2 types of commands in the URL rewriting policy: one replaces part of the URL and the other adds/modifies/deletes query arguments. They're independent, so it does not matter which type we run first (the order of the rules of the same type matters, though).

The other kind of transformation, which we could call named_args (/{orderId}/{accountId}/{incFields} into /sales-order/svc/v2/testDoc/{orderId}?account={accountId}&incFields={incFields}, for example) is a mix of both. It can rewrite parts of the URL, but it can also modify the query args.

This means that the final result depends on the order in which we run this new kind of transformation. I wonder if we should restrict this a bit in order to simplify the rules. For example, we could decide to apply the named_args matching first, and avoid applying the other 2 kinds of transformations when there's a match. Although this could be problematic because I guess that any order can be valid for different use cases.

Reasoning about the transformations performed can become complex when the 3 kinds of transformations are mixed in the same policy. I would recommend not doing so, but still, we should define an order or make it explicit that they shouldn't be mixed. Maybe we should even consider implementing this in a separate policy.

[mikz]

I'm wondering if we are missing something. I guess requests like this will eventually come to other policies too. Matching something and then taking that result and using it for something else.

But because we have just this at the moment, we can focus on solving this one first.

I can see how this could be solved with the conditional policy matching the URL and then storing the matched values in context, so it can be reused later by URL rewriting policy. Of course this would not really be scalable for hundreds of rules.

Maybe some new "request transformation" policy is in order that would be some aggregate of matching and rewriting by using parts of the conditional and url rewriting policy.