validating a body with a schema
amartinm7 opened this issue · comments
Hi!!
I'm trying to do a PUT request with a body. I'm specifying the schema as the documentation says, but it seems like the body validation is not doing anything. ¿any idea?
Here are my json files.
the impostor:
{
"request": {
"method": "PUT",
"endpoint": "/v1/users/123/country",
"schemaFile": "schemas/put-update-account.json"
},
"response": {
"headers": {
"Content-Type": "application/json"
},
"status": 204
}
}
the schema file
{
"country": {
"type": "string",
"enum": [
"SPANISH",
"ENGLISH"
]
},
"required": [
"country"
]
}
the test request
{
"in": {
"method": "PUT",
"url": "http://localhost:8090/v1/users/123/country",
"body": "{\"country\":\"SPANISH\"}"
},
"out": {
"status_code": 204,
"header": {
"Content-Type": ["application/json"]
}
}
}
my krakenD definition
{
"endpoint": "/v1/users/{userId}/country",
"method": [
"PUT"
],
"output_encoding": "no-op",
"backend": [
{
"host": [
"http://my-micro"
],
"encoding": "no-op",
"url_pattern": "/v1/users/{userId}/country",
"circuit_breaker": {
"enabled": true,
"timeout": 2000.0
}
}
]
}
Thanks in advance
Hi @amartinm7,
I have tested your example and it seems to be working correctly, as expected.
What do you see as output when you start Killgrave? 🤔
Make sure that Killgrave is loading correctly your imposters:
- You're pointing to the corrrect imposters directory.
- Your imposters have a valid extension (either
.imp.yml
or.imp.yaml
for YAML or.imp.json
for JSON).
Thanks!
Hi @joanlopez
The previous example is working, but it's not taking account the schema and the body. I mean, if you change the request body with "body": "{"country":"FRANCE"}"... the test is working too... but you expect an error!!. This is my point, the validation is not executed. I don't know why.
Sorry 🙏🏻 Yes, you're right. I assumed the schema you shared was a "subset" of the entire file.
But, if it still fails, I guess it's probably because that's literally your whole file, and I think the problem is that your JSON Schema definition is not completely correct. It should be something like:
{
"$schema": "http://json-schema.org/draft-07/schema#",
"type": "object",
"properties": {
"country": {
"type": "string",
"enum": [
"SPANISH",
"ENGLISH"
]
}
},
"required": [
"country"
]
}
Technically you can omit the $schema
field, but you should:
- Specify the type of the root object
- Move the country, into the root object properties
- Leave the required attribute at the root level.
I have tried it with that, and it works as expected.
Thanks, and apologies for the confusion!
Hi @joanlopez
Using the schema as you say, it's working. So thank you very much for your help :)
But when I'm sending the "body": "{"country":"FRANCE"}" in request, or empty body, I'm getting a 404 error message.
I think the error should be a 400 Bad Request, doesn't it?
I mean, It's a validation error more than if the resource exists or not.
Thxs in advance
Hi @amartinm7,
By default, Killgrave returns a 404 Not Found
for any non-covered endpoint. There has been some discussions about having the possibility of defining a fallback behavior, but so far is not possible.
However, you can still use Killgrave to achieve the behavior you expect with the following imposters definition:
[
{
"request": {
"method": "PUT",
"endpoint": "/v1/users/123/country",
"schemaFile": "schemas/put-update-account.json"
},
"response": {
"headers": {
"Content-Type": "application/json"
},
"status": 204
}
},
{
"request": {
"method": "PUT",
"endpoint": "/v1/users/123/country"
},
"response": {
"headers": {
"Content-Type": "application/json"
},
"status": 400
}
}
]
So, basically, you're defining an imposter to respond to PUT /v1/users/123/country
requests that satisfy your schema with 204 No Content
, and another one to respond to PUT /v1/users/123/country
requests with 400 Bad Request
. So, if you order them (remind that order matters!) as in the example above, the correct requests will satisfy the schema, and fall into that imposter (returning a 204 No Content
), while the incorrect requests will fall to the second imposter (returning a 400 Bad Request
) , which has no requirements other than the method and the path.
I hope that helps you!
Hi @joanlopez
Yes, it helps. Thxs a lot! :)