-
Notifications
You must be signed in to change notification settings - Fork 41
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Response body/format validation #159
Comments
Hey @marceloverdijk sorry about the confusion, the command I think it makes sense for chanfana to also check for the response formats. It should be a 2-step validation, first typescript error when the returning object is not in the same format, and then clean the response object to allow only defined arguments to be returned. |
Thx @G4brym for sharing! I will pay attention to that PR.
But for now I will just copy some setup from your repo into my project ;-) Also thx for confirming the way I'm handling the response body validation. |
Hey guys, I am trying to get this to work, but am stuck on a 404 Bad Request. Here is my endpoint code:
And here is my router code:
These are the versions that I am using:
I have tried taking const data = await this.getValidatedData(); out of the try{} block, but then the whole thing collapses with:
What am I doing wrong? |
@patrickcneuhaus I think you are only missuing the removal of |
Hi @G4brym, I tried to follow the example. It begins with the following import: However, I am getting: |
@patrickcneuhaus I think it needs to be:
(and same for |
Thanks @marceloverdijk! It works 👯 Probably a good idea to update the docs accordingly though |
I just found out that itty-router-openapi was renamed/changed to chanfana, and I really like the concept 👍
Class-based endpoints and then either using Hono or itty-router.
I wanted to try and created a new app using
One part I'm missing is body response validation is that correct?
"Funny" thing is that even some of the example endpoints generated with
-type openapi
do not follow the defined response schema, e.g.:The response should contain
{ success: true, result: { task: .. } }
as defined in the schema, and not{ success: true, task: .. }
as actually returned.Validating (and/or auto cleaning) responses is important for:
Especially the latter is important when e.g. quering records from a database, but not all properties should be exposed.
What I'm doing currently is:
This uses the zod
parse
function on theTaskSchema
to validate all required properties are there, and cleans out all properties part of the task, but not part of the schema.I'm wondering if this is the best approach, or chanfana could provide something for this out of the box?
The text was updated successfully, but these errors were encountered: