Support differing order of params about pact-specification HOT 16 CLOSED

disagree

from pact-specification.

@edanielsen, we're currently writing a pact specification, and going through each part of the request to work out what the matching rules should be. Having done a bit of poking around on the internet about the query string, I'm not entirely sure that we can say that order should not matter. For example, if you have two parameter with the same name, they essentially become an array, and order COULD matter.

from pact-specification.

However, there are a set of feature requests with a similar theme, all around being less strict on the request.

Assuming we want to allow for non-strict requests (which is not necessarily the case) we could consider adding some more metadata for v2 of pacts.

• Allow different order of query params, or additional parameters
• Allow all sorts of madness in the headers (the javascript guys have a lot of trouble there with cookies and CSRF flags)
• Allow extra junk / regexes in the request body

So it wouldn't be the default, but could be switched on in the DSL for specific pacts.

While I'm somewhat opposed to it on phillosophical grounds, I don't feel it's appropriate to use that as a factor in the decision.

The important factor would be the cost of increased complexity in the matchers for each language

from pact-specification.

I'll probably repeat myself as I've mentioned similar idea in the related issue but here it goes.
Based on current philosophy of being strict by default what if you leave the current implementation and call it strict mode. All marchers in every language should at least implement the strict mode.
Then, in contract json there could be some kind of options array which will have ignore_paremeter_order: true and other matcher options. Each matcher implementation should be able to tell which options it supports and if a matcher in e.g. Python doesn't support ignoring of parameter order due to some std lib python constraint( just making things up) it will throw exception(or print warning) if user gives it a contract with options it can't handle.
Thoughts ?

from pact-specification.

Here is a gist of a way I've been thinking of to serialise matching information about the pact file, for pact-specification 2. https://gist.github.com/bethesque/5a35a3c1cb9fdab6dce7

The option that you speak of could go in the responseMatchers section.

from pact-specification.

@uglyog If we are going to make the order not important for one implementation, then we need to do it for all implementations, and make them consistent, and part of the pact-specification.

Two things

1. you can have the same parameter specified multiple times, so a hash is not the right data structure to represent the parameters.
2. sometimes the ordering of params could be important, for example, when representing an array. ?blah=thing1&blah=thing2&blah=thing3

from pact-specification.

A map of key -> array of values would retain the order of values, so:

blah=thing1&blah=thing2&blah=thing3 would become Map(blah -> [thing1, thing2, thing3])

In my example, the query strings q=p&q=p2&r=s and r=s&q=p&q=p2 would be equal because they will have the following structure:

Map(q -> [p, p2], r -> [s])

while q=p&q=p2&r=s and q=p2&q=p&r=s would not because

Map(q -> [p, p2], r -> [s]) != Map(q -> [p2, p], r -> [s])

I like the idea of @Maxim-Filimonov in having a strict versus non-strict mode, where strict mode compares the actual query string, while non-strict compares using the map structure.

from pact-specification.

Map with arrays makes sense, and addresses the 95% usecase of "ordering of different named params doesn't matter, but ordering of the same named params does".

Got ideas on how to DSL and serialize the strict versus non-strict modes?

from pact-specification.

I am personally inclined to just do the structure matching on the map of arrays, and not support strict mode. I think needing to specify the order of differently named params is such a corner case that there's probably little value in supporting it. Most frameworks don't even retain the order, as params are generally exposed as a hash.

from pact-specification.

@bethesque correct me if i'm wrong but I think in rails the order of parameters matter for array composition. For example, arr[]=1&arr[]=2 gives you params[arr] = [1,2] while arr[]=2&arr[]=1 gives you params[arr] = [2,1]. So i'm not sure how much of corner case is that, Rails is quite popular framework after all.

from pact-specification.

I agree - what I was saying was that order does matter when the params have the same name, but order does not tend to matter between params with different names.

So arr[]=1&arr[]=2&foo=bar should be considered a match for foo=bar&arr[]=1&arr[]=2, but not a match for arr[]=2&arr[]=1&foo=bar

from pact-specification.

ah my bad - misunderstanding is my second name 🚼
👍 on ignoring order for differently named params. If someone comes up with a compelling case where it does matter we can come back to this discussion and than do multiple modes.

from pact-specification.

Having decided that we want to allow flexible ordering of params, except when the params have the same name, it makes sense for v2 to allow the params to be specified in a hash in the consumer DSLs, and to be serialised as a hash in the pact json.

  some_provider.upon_receiving("a request for something").with(
    path: "/something", 
    query: {
      "param1" : like("blah"),
      "param2" : [ eg("123", /\d{3}/), eg("456"  /\d{3}/ ]
   } 
  )

{
  "query": {
    "param1": ["blah"],
    "param2" : ["123", "456"]
  }
}

Should we serialize every param value as an array, even if there is only one value? It would make it more explicit what sort of matching is being done, and work better for statically typed languages I'd expect.

from pact-specification.

I think the Map name to Array is the best solution. It will make it easier
to implement in Scala.

The Pact-JVM currently converts it into this structure internally.

On 11 October 2014 10:24, Beth [email protected] wrote:

Having decided that we want to allow flexible ordering of params, except
when the params have the same name, it makes sense for v2 to allow the
params to be specified in a hash in the consumer DSLs, and to be serialised
as a hash in the pact json.

some_provider.upon_receiving("a request for something").with(
path: "/something",
query: {
"param1" : like("blah"),
"param2" : [ eg("123", /\d{3}/), eg("456" /\d{3}/ ]
}
)

{
"query": {
"param1": ["blah"],
"param2" : ["123", "456"]
}}

Should we serialize every param value as an array, even if there is only
one value? It would make it more explicit what sort of matching is being
done, and work better for statically typed languages I'd expect.

—
Reply to this email directly or view it on GitHub
#2 (comment)
.

from pact-specification.

A map of key -> array of values has been added to V3

from pact-specification.

Going to consider this as closed as v3 is released

https://github.com/pact-foundation/pact-specification/tree/version-3

Feel free to re-open if not

from pact-specification.