If the query params are added in the matching url config, throws ''URL does not match' error .
Documentation says, it is allowed.
I think this can be fixed if we strip off query params before stubbing in the"urlPathEqualTo" method, to allow only path part further. @tomakehurst Can i submit a PR for this?
Another thought on this, what if we autodetect query params and populate them with wildcards?
Maybe have an option that enables/disables this behavior or a builtin transformer that does this.
Will it blow up if we see the same requests with some query params missing/extra? Just thinking out aloud.
@sandarsh Isnt the purpose of "urlPathEqualTo" to match only the path and not the query params? For matching query params, there exists urlEqualTo and urlMatching. Currently urlPathEqualTo doesnt match if stubbed with query params (as they are not removed before stubbing)
I'm thinking it'd be a good idea to fix this in the next major version rather than now. I've looked at this issue a couple of times in the last year or two, and all the available solutions seem to involve potentially breaking existing behaviour.
I'm seriously considering dropping the ability to specify path + query in the URL field entirely in 3.0, so that queryParams is the only option if you need to match on query parameters. That way validation error could be thrown if a ? appears in the path.
A quick workaround that worked for me was to add the url params in the matching url.
For example, in the mappings json file:
{
"request": {
"method": "POST",
"url": "/api/account?locale=en&device=x86_64®_lat=-12.228755&platform=ios®_lng=-76.928355"
},
"response": {
"status": 200,
"bodyFileName": "login.json"
}
}
Note: The url params must be in the same order as in the production url
When it comes to evaluating the path without query parameters, you can go with 'urlPath' and 'urlPathPattern'.
Both do match the path, even if query parameters are part of the URI.
{
"request": {
"method": "GET",
"urlPath": "/api/transactions"
}
}
matches:
GET /api/transactions?offset=10&limit=10
+1
Most helpful comment
I'm thinking it'd be a good idea to fix this in the next major version rather than now. I've looked at this issue a couple of times in the last year or two, and all the available solutions seem to involve potentially breaking existing behaviour.
I'm seriously considering dropping the ability to specify path + query in the URL field entirely in 3.0, so that
queryParamsis the only option if you need to match on query parameters. That way validation error could be thrown if a ? appears in the path.