How can one validate optional parameters? In this case EVENT BODY #1246
Replies: 7 comments 2 replies
-
You could put the validate in the method handling only the "PUT" or "GET", then you schema can be specific to that method only. |
Beta Was this translation helpful? Give feedback.
-
Oh yea, each API method has its own schema definition. I guess what I mean is to support something like "Partial", like in Marshmallow. |
Beta Was this translation helpful? Give feedback.
-
Yea so an easy test for this is to have "required" : [], the validate function will not validate anything (At least in my experience). I believe its the same as omitting the required keyword altogether in the schema definition. Thanks for your help. I kind of assumed you could declare the fields as "optional" or something similar, but still have validation for that field (such as max_length) |
Beta Was this translation helpful? Give feedback.
-
Hey @jgasyna your use case will be best handled by Parser (Pydantic): https://awslabs.github.io/aws-lambda-powertools-python/latest/utilities/parser/ While you could use optional fields in JSON Schemas, I can see you have experience with marshmallow so Parser/Pydantic will feel like second nature to you. |
Beta Was this translation helpful? Give feedback.
-
So after some poking around, it appears that it is actually best "REST" practice to send the whole payload in a PUT operation. This will solve the issue above. (So basically the diff between a PUT and PATCH). It is still strange, however, that optional / partial field are not supported in API GATEWAY power-tools validation. I guess I would suggest a feature request to support PATCH API calls in the future. |
Beta Was this translation helpful? Give feedback.
-
Sorry typing on my phone and forgot to send the link to Draft 7 of JSON
Schema on conditional validation.
http://json-schema.org/draft-07/json-schema-release-notes.html
There’s an “if” “else” in JSON Schema that you could define a required
field optional IF X == Y (“PATCH”).
In my humble opinion, this is problematic in JSON Schema because it turns a
stateless validation into an inflexible format to handle varying states -
it could go wrong easily if your number of dependent fields grow, hence the
suggestion to consider Parser.
Example
{
"type": "object",
"properties": {
"foo": { "type": "string" },
"bar": { "type": "string" }
},
"if": {
"properties": {
"foo": { "const": "bar" }
},
"required": ["foo"]
},
"then": { "required": ["bar"] }
}
…On Mon, 13 Jun 2022 at 20:40, Heitor Lessa ***@***.***> wrote:
Perhaps I misunderstood your question completely. When you have the
bandwidth, could you open up a feature request on this?
Powertools Validator uses fastjsonschema library to validate dicts using a
JSON Schema. If this is supported in JSON Schema (optional fields are a
feature), then we should look into this.
For strict typing at runtime, deep and conditional validations, and data
remapping/scrubbing Parser utility is best.
If you don’t have the bandwidth and could share a sample anonymised
payload and the expected outcome you’d like, we’re happy to create it on
your behalf.
Thank you
On Mon, 13 Jun 2022 at 20:11, jgasyna ***@***.***> wrote:
> So after some poking around, it appears that it is actually best "REST"
> practice to send the whole payload in a PUT operation. This will solve the
> issue above. (So basically the diff between a PUT and PATCH). It is still
> strange, however, that optional / partial field are not supported in API
> GATEWAY power-tools validation. I guess I would suggest a feature request
> to support PATCH API calls in the future.
>
> —
> Reply to this email directly, view it on GitHub
> <#1246 (comment)>,
> or unsubscribe
> <https://github.com/notifications/unsubscribe-auth/AAZPQBFPQD223QS7DFMHM5DVO52VBANCNFSM5YOZRFYQ>
> .
> You are receiving this because you commented.Message ID:
> <awslabs/aws-lambda-powertools-python/repo-discussions/1246/comments/2940927
> @github.com>
>
|
Beta Was this translation helpful? Give feedback.
-
Perhaps I misunderstood your question completely. When you have the
bandwidth, could you open up a feature request on this?
Powertools Validator uses fastjsonschema library to validate dicts using a
JSON Schema. If this is supported in JSON Schema (optional fields are a
feature), then we should look into this.
For strict typing at runtime, deep and conditional validations, and data
remapping/scrubbing Parser utility is best.
If you don’t have the bandwidth and could share a sample anonymised payload
and the expected outcome you’d like, we’re happy to create it on your
behalf.
Thank you
…On Mon, 13 Jun 2022 at 20:11, jgasyna ***@***.***> wrote:
So after some poking around, it appears that it is actually best "REST"
practice to send the whole payload in a PUT operation. This will solve the
issue above. (So basically the diff between a PUT and PATCH). It is still
strange, however, that optional / partial field are not supported in API
GATEWAY power-tools validation. I guess I would suggest a feature request
to support PATCH API calls in the future.
—
Reply to this email directly, view it on GitHub
<#1246 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAZPQBFPQD223QS7DFMHM5DVO52VBANCNFSM5YOZRFYQ>
.
You are receiving this because you commented.Message ID:
<awslabs/aws-lambda-powertools-python/repo-discussions/1246/comments/2940927
@github.com>
|
Beta Was this translation helpful? Give feedback.
-
Powertools validation work great for a Create (POST) with a body full of required fields. However, how would you still use the same validator for an edit / update API (PUT). Lets say we have an existing user profile and want to update the first_name field only.
You call PUT with only the "first_name" parameter and new value. I still want to validate that one field while the other fields are not there. I cannot define "required" in this case because it can be any of the original fields, and if I leave out the "required" array definition, it does not validate anything.
Using aws-lambda-powertools==1.25.10
Calling:
validate(event=event, schema=input_schema, envelope=envelopes.API_GATEWAY_HTTP)
Where the body can have artbitrary amount of the parameters on an update API.
"first_name": {
"$id": "#/properties/first_name",
"type": "string",
"max_length": 100
},
I still want to validate that it is < 100 chars
I cannot define "required": ["first_name", ... , .... ] in this event
Beta Was this translation helpful? Give feedback.
All reactions