New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Query string policy: Manipulate request URI query string #711
Comments
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: |
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: 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. |
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 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 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. |
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. |
Use Cases
/{orderId}/{accountId}/{incFields}
into/sales-order/svc/v2/testDoc/{orderId}?account={accountId}&incFields={incFields}
. This should work when request URL containsaccount
orincFields
parameters in the query string. ("Rewrite URL captures" policy #827)foo=bar
in the query string and replace it byfoo=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
The text was updated successfully, but these errors were encountered: