Closed jinyoung closed 11 months ago
I was suspicious myself, so I did some additional testing based on the officially obtained open API example from the Microcks:
https://raw.githubusercontent.com/microcks/microcks/master/samples/APIPastry-openapi.yaml
I tried :
launch the mock service with above openapi 3 spec:
npx @stoplight/prism-cli@latest mock https://raw.githubusercontent.com/microcks/microcks/master/samples/APIPastry-openapi.yaml
list api works well:
$ http :4010/pastry
HTTP/1.1 200 OK
Access-Control-Allow-Credentials: true
Access-Control-Allow-Headers: *
Access-Control-Allow-Origin: *
Access-Control-Expose-Headers: *
Connection: keep-alive
Content-Length: 378
Content-type: application/json
Date: Tue, 17 Oct 2023 00:51:50 GMT
Keep-Alive: timeout=5
[ { "description": "Delicieux Baba au Rhum pas calorique du tout", "name": "Baba Rhum", "price": 3.2, "size": "L", "status": "available" }, { "description": "Delicieux Divorces pas calorique du tout", "name": "Divorces", "price": 2.8, "size": "M", "status": "available" }, { "description": "Delicieuse Tartelette aux Fraises fraiches", "name": "Tartelette Fraise", "price": 2, "size": "S", "status": "available" } ]
3. the get api for specific id works well too, but the expected example (the matching response would be value of 'Millefeuille') wasn't returned but the default example was returned
$ http :4010/pastry/Millefeuille HTTP/1.1 200 OK Access-Control-Allow-Credentials: true Access-Control-Allow-Headers: Access-Control-Allow-Origin: Access-Control-Expose-Headers: * Connection: keep-alive Content-Length: 113 Content-type: application/json Date: Tue, 17 Oct 2023 00:52:31 GMT Keep-Alive: timeout=5
{ "description": "A short description os my pastry", "name": "My Pastry", "price": 4.5, "size": "M", "status": "available" }
4. the patch api returns wrong validation too. (price must be number even if I gave the 10.5 which is proper number input with httpie)
$ http patch :4010/pastry/M illefeuille price=10.5
HTTP/1.1 422 Unprocessable Entity Access-Control-Allow-Credentials: true Access-Control-Allow-Headers: Access-Control-Allow-Origin: Access-Control-Expose-Headers: * Connection: keep-alive Content-Length: 372 Date: Tue, 17 Oct 2023 00:54:22 GMT Keep-Alive: timeout=5 content-type: application/problem+json
{ "detail": "Your request is not valid and no HTTP validation response was found in the spec, so Prism is generating this error for you.", "status": 422, "title": "Invalid request", "type": "https://stoplight.io/prism/errors#UNPROCESSABLE_ENTITY", "validation": [ { "code": "type", "location": [ "body", "price" ], "message": "Request body property price must be number", "severity": "Error" } ] }
Hi @jinyoung, it looks like the default behavior for httpie is to pass variables as strings according to their documentation. In order to pass a body param as an integer you have to use the :=
syntax. So you're actually sending Prism a string and not an integer for those body params, so Prism's response is correct and expected. You can also use the --print
option as outlined here to see what request you're actually sending Prism.
Context
I have this oas3.0 definition with request body with properties in integer type:
Current Behavior
It returns the request validation error like this:
Expected Behavior
It should return the matching example with no validation errors
Possible Workaround/Solution
When I change the property types to 'string', it works.
Steps to Reproduce
Environment