So I couldn’t really find a confirmed answer when I tried to look at related questions. I’m confused about the “request” body matching option that can be configured for Mock Servers. To my knowledge, there are two ways we can configure request body matching: 1) via the "Mock Server Configuration page → clicking the checkbox next to “Match Request Body” or 2) By setting the "x-mock-response-body header to true for the request & saved examples.
Does the request body from an incoming request have to perfectly match the mock “request body” set for one of the examples? Like is there a way to modify or customize the logic so that we only match/look for the important fields in the request and ignore the rest?
For example: Suppose I want to match a request body that contains a “first-name” field with the value “John” to a corresponding John example but I don’t care if the request has additional fields. So, for instance, if I get an incoming request like:
{
"first-name": "John",
"attributes": { "f1": 3, "f2": 1 }
}
This should still map to the “John” example even if it has additional fields because I only care about the first-name field. How can I configure the request body for the example so that the above request would get matched to it? Is there a way to specify wildcard/ignore field attributes or anything like that?
1 Like
Understanding example matching | Postman Learning Center
If you always want it to return the john example, then its sounds like you need to use the x-mock-response-id header.
Hi mdjones, thanks for responding!
No. To clarify, I don’t want to match based on headers or query parameters, only the request body. So that means I don’t always want it to return the John example. I’m saying that I would like to return the John example if an incoming request has a body which contains the “first-name” field whose value is set to “John”.
But the question I am asking is whether we can configure this “request body matching” mechanism so that we only match the important fields (like “first-name”) rather than requiring an exact body match (which is what currently seems to be the case). I want to ignore extra fields for example.
You can’t change the matching algorithm. It is what it is.
If you don’t want to use the headers, then you are reliant on the matching algorithm, which is explained in the previous link.
As far as I can tell you have to turn on exact body matching using a header.
Therefore, have you tried it with the body as you are suggesting.
It will either work or it won’t.
1 Like
I quickly tested this, and the attributes do matter, otherwise it just returns the first example.
I’ve created two examples with the same structure, with the second example having a different name. For example “David”.
I can target both of the example by providing the same structure and correct name.
If I put in a different name “Peter” that is not in the example, then it defaults to the first example “John”.
If I rename the attributes key on the second example, and try and retrieve “David”, it defaults to the first example “John”.
If I leave the attributes key alone, but add another element, it also defaults to the first example when its not an exact match.
I can’t see how you would target this specific example, without using the headers.
1 Like
Just adding a +1 to this.
We recently came up against this limitation and couldn’t resolve it. Our scenario was that we had a dynamic property on the request that we couldn’t control e.g., timestamp, a property which just holds the current date/time. There’s no way to statically pre-configure this in an example request because it is constantly changing. Therefore, you can’t use request body matching.
Unfortunate.
1 Like
Yeah, I ran into this issue as well. My fix was that I added a check in the code so that for test environments, we explicitly set these types of values like timestamp or app_id (a UUID type) to a fixed value (for ex. first-name) that we can also set on the saved examples.
By doing this, I could then continue to use request body matching.
1 Like