Confused: do microcks validate requests?

[LeonidShl]

I am trying to create my first microcks-powered api mock. I prepared some rest openapi spec, but when I try to use it it seems like my requests are not validated against the provided schemata. Does the microcks perform it by default?

[lbroudoux]

Hi @LeonidShl
Microcks does not currently perform client request validation while mocking. We could add this optional check later.
However, Microcks validates responses against API schema when launching tests. See https://microcks.io/documentation/explanations/conformance-testing/

[LeonidShl]

Hello Laurent, thank you for the answer. My goal is to investigate and find the simpliest to use mocking framework, exactly for mocking purposes, to create a bunch of working mocks for microservices, given the openapi schemata. Microcks did the job, but with some problems. first was the ability to validate requests. Actually, all things for that are already provided by the schema, but to implement it in microcks I must do this in script, copying the part of schema into it. (so, the schema is not a single source of truth anymore). Heplpful were to expose schema in mockRequest object (just to use it by validation by script), or validate the requests by microcks.

Second thing - bad documentation of APIExamples: there is no code property in examples, it named "status"

Third thing - there is no way to configure mock parameter constraints via APIMetadata file

Fourth: if we do constraints, ie I restrict value of some header to match some regex - why do I automatically get error 400 back? Why not ie 401? It were ideal if I can set some of mock responses here...

Okay, and may be probably many othen things, but, if the microcks has other goals than just create mocks, they are not relevant..

[lbroudoux]

Hey @LeonidShl

Thanks for the feedback and for sharing your points. I think we have some stuff in the pipe for you.

1. Request validation was actually implemented on the SOAP side but not reported in REST mocks. I think it would be easy to open a Request For Enhancement and add it as well there.
2. The code/status mismatch should have been fixed now. It was raised here: [APIExamples] - Incoherency between schema and code  #1278. I will double-check if the doc is still lagging or not.
3. We have a user on the Discord that asks for that and that should create a RFE for that.
4. 401 is for unauthorized - while 400 is for a malformed client request. If a client request doesn't respect constraints, then I think it makes sense to have a 400. We can't know if it's related to security or not.

Let us know if 1. would be useful for you. We'd be happy to see if it can fit in next release.

[LeonidShl]

Hello Laurent, yes, 1 will be very very helpful

[lbroudoux]

Please check #1366 and feel free to follow-up/comment/enrich the discussion there.

[kaos]

Moving a thread from Discord here:

How much payload validation is applied when mocking calls?
The only reference in the documentation I could find is when using the OPEN_API_SCHEMA test runner, it says that the response payload is validated against the schema.
Is the request also validated against the schema?
And when running as a mock or proxy what validations are done then?

Comparing to https://stoplight.io/open-source/prism a nice feature they have is that not only are the examples validated against the schema, but when running in proxy mode, it validates both the request payload as well as the response payload, ensuring both client and server are compliant with the spec.

What we would like to see, is a way to enable schema validation on all request/response data (possibly on a per example/endpoint basis to facilitate "bad/invalid examples")

[lbroudoux]

What I have in mind for REST request payload validation would be to enable it via a different endpoint.
For example:

• We have the regular, existing /rest/API+Pastry/1.0/... endpoints without request payload validation,
• We would have a new /rest-valid/API+Pastry/1.0/... endpoints that performs request payload validation before routing to the first one if the payload conforms to the schema.

Regarding mock response validation, we took a different approach at the moment as we don't validate example responses at import time. We do think that it's the designer or linter tooling responsibility to do this (BTW, we provide https://github.com/microcks/microcks-spectral-ruleset to ease that), and thus, we allow integrating bad responses - and that's super useful if you also want to simulate errors (like truncated content...)

However the response validation feature could be also turned on when we're using the PROXY or `PROXY_FALLBACK``
dispatcher style. Have to think about it on how we would allow that...

[kaos]

Cross ref to #1390