Allow multiple matchings for requests about restmock HOT 5 CLOSED

By complexity I mean actually the purpose of the library. I want the Hamcrest matchers be the only source of truth for the end user, while more complex logic should be a part of his own code, this has 2 benefits:

• I don't have to maintain too much of complex code that will satisfy 10% of the users
• More complex matching of responses should be a part of your own code, so you don't need to debug library code to understand what happened wrong.

I think that better approach than prioritizing responses is to provide you with a mechanism of determining response on per-request basis in the following way:

RESTMockServer.whenGET(pathStartsWith("login"))
                .thenAnswer((request) -> {
                    if (not(hasQueryParameters()).matches(request)) {
                        return new MockResponse().setBody("NOT OK").setResponseCode(401);
                    } else if (hasQueryParameterNames("user","pass").matches(request)) {
                        return new MockResponse().setBody("OK").setResponseCode(200);
                    }
                    return null;
                });

This mechanism is a part of the next release #74

from restmock.

definetely something to consider! will come up with approach and let you know here and will be a part of the next version. Thanks!

from restmock.

I don't really see much complexity in having a priority parameter. In my head, it would not be part of the hamcrest matchers, so without adding priorities everything would work like right now. Priorities would only be considered when there are multiple matching responses (in MatchableCallsRequestDispatcher#dispatch() -> else if (matchedCalls.size() > 1) {). I imagine something like this:

if (matchedCalls.size() == 1) {
    return onOneResponseMatched(recordedRequest, matchedCalls);
} else if (matchedCalls.size() > 1) {
   // -> New logic
    List<MatchableCall> highestPriorityCalls = takeHighestPriority(matchedCalls)
    if (highestPriorityCalls.size() == 1) {
        return onOneResponseMatched(recordedRequest, highestPriorityCalls);
    } else {
        return onTooManyResponsesMatched(recordedRequest, matchedCalls);
    }
    // <- New logic
} else {
    return onNoResponsesMatched(recordedRequest);
}

Where the priority would be an optional attribute of MatchableCall, and not part of its Matcher<RecordedRequest>. (The code could probably be more clean, it's just to show the idea)

Is this also what you thought? What do you think of that approach? Does it still add too much complexity?

My login request scenario was just one example, we have more scenarios where we need some way to overwrite the same request for particular cases.

Anyways, if you don't feel this is something you'd like to have in the library it's totally OK. We can always fork the code or implement a custom dispatcher for ourselves :)

from restmock.

I've had a thought on this and am rather reluctant on introducing the priority, since it will make matching responses more complex by adding one additional layer which will make it way harder for debug if you specify priorities incorectly. We here are dealing with hamcrest matchers that let us do very complex matching rules themselves. This particular issue you've mentioned could be solved with matchers, like:

/api/login -> allOf(pathEndsWithIgnoringQueryParams("login"), not(hasQueryParameters()))
/api/login?user=me&pass=123 -> allOf(pathEndsWithIgnoringQueryParams("login"), hasQueryParameterNames("user", "pass"))).

Both of those matchers will be introduced in the upcoming release pretty shortly.

Please share your thoughts

from restmock.

Aha, ok I understand. You're right, priorities would mean introducing a new concept for matchings.

I will try to satisfy all of my requirements with your suggestions.

Thanks a lot @andrzejchm for the new mechanism and for all your work on this library :)

from restmock.