Hi everyone. I have come across the following issue(s) and was looking for some feedback. Background We had been using a API Virtualization Tool to simulate our APIs. But this tool was $$$ and required pretty extensive development to simulate our APIs. A decision was made to not renew the license and move back to simple mocking — our WSO2 branded API Gateway uses WireMock and we have access to WireMock Cloud for create a WireMock mapping file for our OAS 3 Swaggers. Experience with WireMock Cloud OAS to Mapping For example, in our Swaggers we have an endpoint

POST /documents

that is used to upload a document. In the Swagger we have multiple responses defined: 200, 400, 401, 403, 422, 500, 502, 503, 504. I went ahead and processed that Swagger and downloaded the WireMock mapping file. In looking at the mapping file I see that it creates mappings for all of our response definitions for each endpoint. In that mapping file for uploading a document (

POST /documents

) I see a group at the top of the file for: • 200 • 401 • 403 As the WireMock documentation shows, the default priority if none is specified is “5”. Further down the file (in this order) I see the mappings for the following: • 400 - priority 8 • 422 - priority 9 • 500 - priority 10 • 502 - priority 10 • 503 - priority 10 • 504 - priority 10 Auto-Generation Issue So my issue with the auto-generated file is that when I call this created mapping file I would expect to get the 200 response. But the WireMock rules for matching are: • Highest Priority (lowest #) • If the same priorities, the last physical definition read in the file So in this case I receive a 403 as the response. To get the 200 response I want, I need to define a priority higher than 5 (1-4) for that mapping. So my questions for the WireMock team would be: • Is there any reason to generate mappings for the 4xx or 5xx responses? Normally these would only come back because of a business logic rule failure or server failure. ◦ I could see a general 404 as a low-priority global match for GETs • If there is a reason to generate all of the response codes, then maybe have settings where I can ◦ Have the 2xx entries set to a priority I specify (like 1) ◦ Explain the reasoning for the priorities shown above (some 4xx are default, 400 is a 8, and 422 a 9). ◦ Is there a way I could add a header or path parameter specifically for WireMock to trigger a specific response mapping? ▪︎ Like header/path parameter of “wiremock-response-code” set to some value like 400, 422, 501, etc. • Another separate option for generation would be to ignore any “server” definitions in the OAS file. That server context-path was added to my defined context-path. Thanks for any/all help - Brian

Hi Brian, to answer your questions in turn: • We generate 400 and 422 because there’s an option (currently available via the API only but will be in the UI soon) to require that the main 2xx response requires that the request match the JSON Schema constraints for all declared parameters. Otherwise we fall through to either 400 or 422 depending. I agree that some other status codes can be unreachable or not useful as generated, but with some hand-editing (e.g. to require/avoid a specific auth header value) can be useful to have. • 2xx responses should be higher priority when there’s no JSON schema in • Agree we need a bit more flexibility here, although there is an API-only parameter that’ll flip the relative priorities of 400 and 422 so you can choose which style to go for (some APIs will use 400s for all bad requests, some only when it’s not the request entity that doesn’t match). • You can edit stubs to achieve this behaviour - adding an additional one of a high priority with the header in question would do it. There isn’t a way to make this happen via an OpenAPI import though. • Currently if the context path is present we’ll use it I’m afraid, so if you don’t want it to be included you’d need to remove it from the doc. Check this out for how to enable JSON schema matching for 2xx responses and flipping the 422/400 priority. The first of these might help avoid the situation where your 4xx is getting matched when you want a 2xx: https://github.com/wiremock/wiremock-cloud-postman-collections/blob/main/open-api-import/ImportingFromOpenAPI.postman_collection.json This is an area we’re actively developing at the moment and we know we haven’t got it completely right yet, so we appreciate your detailed feedback. I hope I’ve managed to clarify things a bit here, but I’m happy to discuss this in more detail on Zoom if that would help.