Admin static json mappings

[wiremock-net]

Admin static json mappings

[StefH]

WireMock.Net.StandAlone
There should be no need for Newtonsoft.Json; I did fix the app.config

[StefH]

Static Mappings using a json file is not yet implemented. I'll build this in some time using this thread for updates.

[StefH]

Support added.

See example project on how to use this.

[phillee007]

Nice :-) I added a method to do it myself but hadn't tested enough to submit a PR. Will get the latest when I'm back at work on Monday and try it out Thanks! On 10/02/2017 9:16 PM, "Stef Heyenrath" <[email protected]> wrote: Support added. See example project onhow to use this. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#21 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AEEFo1sFxFLZxkl-WZCNEiwxYz9UAt_Uks5rbBzAgaJpZM4L8zMR> .

[StefH]

Did you have time to verify this?

[StefH]

@phillee007 Is it working fine?

[phillee007]

finally got a chance to test this!

To answer your question: yes and no...

Yes it can read mappings files that are named using a guid, however, we find it useful to actually use meaningful file names, as we're generating a whole heap of static mappings based on log files from real requests/responses from our external api. E.g. customer_get_123.json vs asdfdsafsaf234324.json

Is it possible for the static mappings reader to just read all .json files in the directory rather than forcing them to use a guid? Maybe add an optional filename property to the Mapping class so we can specify that if/when calling the admin api to add mappings at runtime too?

Thanks,
Phil

[StefH]

Good point.

I will add support for all .json files and add a title to the mapping which will be used as filename if present.

[StefH]

OK. I've added a "Title" as property. Can you please get the latest code and test if this works for you ?

[StefH]

Were you able to test the latest code?

[phillee007]

Good news - I got to test this at last and it does work! Will raise another issue regarding the path matching and full urls separately

[phillee007]

Actually, scratch that comment re raising another issue. I see you've already added in the extra function to convert a relative url to the fully qualified url so that matcher works :-)

E.g. If the request has something like this:
...
Url": {
"Matchers": [
{
"Name": "WildcardMatcher",
"Pattern": "products/123456"
}
]
},
...

When I was using the earlier version of wiremock.net, it required me to have the fully-qualified url in the Pattern otherwise it wouldn't find the match when I requested http://myserver:9090/products/123456. E.g.

...
"Pattern": "http://myserver:9090/products/123456"
...

However, I see now that I can just specify the relative url and it works as per the regular WireMock documentation.

Great work!!! We're now ready to use this fairly heavily so will let you know if we hit any other issues

[StefH]

Thanks. Please open new issues in case you encounter something.