Feature: support BodyAsJson for Request in static mapping files.

[DavidKorn]

Per comment from @StefH in #153, I'll work on a PR for this:

I think the shortcoming with using the MatcherModelMapper for JSON body matching is that the Pattern must be a string. A static mapping would have to escape out all the double-quotes and do the whole JSON on one line, which really hampers readability.

Let's support the BodyAsJson property on the static mapping Request definition and let it just take an object (and not a Matcher definition). So this would look just like the BodyAsJson in the static mapping Response. BodyAsJson will trigger an exact JSON serialization comparison with the incoming request body. This would be very clean to read and alter in the mapping file, and I think it would well suit a common use case. If more flexibility is needed, the JsonPathMatcher on the Body can be used instead.

Further, if the proxy recorder came across a serializable JSON body in the request, it can record this as a BodyAsJson property for the static mapping file rather than translate it into an ExactMatcher as it currently does. (The drawback we're seeing for the ExactMatcher is that if the recorded call indented the JSON body but a later caller doesn't, we don't get a match.)

[DavidKorn]

I pushed up a PR for this. I did not go as far as supporting BodyAsJson having a single JSON value in the Request mapping model, because I wasn't sure if it drifted too far from the existing design. But I did add a JsonObjectMatcher for JSON body matching without escaped strings, and I set it for use with the proxy recorder when recording a request that has a BodyAsJson.

[StefH]

Thanks a lot for your PR, however I did solve this issue in a different way, I hope you're not offended ;-)

I added code to JsonMatcher to support both : object and string. Please review my branch at https://github.com/WireMock-Net/WireMock.Net/tree/stef_JsonMatcherFix

[DavidKorn]

Haha, that's a much bolder refactor! It seems to add some flexibility, so that's great. I wasn't sure you'd want to generalize Pattern that much since it seems to be string in all other places, but I happily defer to your vision.

At this point, is IValueMatcher still needed separately from IObjectMatcher? IStringMatcher already has string [] GetPatterns() so maybe IObjectMatcher could just get object GetValue() ?

I really appreciate you jumping on this, and we're eager to put it to use. Will you be promoting this version to Nuget or shall we depend on a fork for the time being?

[StefH]

For now I'll keep the IValueMatcher. BTW I did send you invite to join this project.

[StefH]

And maybe join the gitter @ https://gitter.im/wiremock_dotnet/Lobby

[StefH]

New NuGet 1.0.4.2 is uploaded.