Validate response objects

Using the zod validator middleware it is possible to validate params , query, request body like:
const route = app.post(
'/posts',
zValidator(
'form',
z.object({
body: z.string(),
})
),
(c) => {
// ...
return {
..
}
}
)
const route = app.post(
'/posts',
zValidator(
'form',
z.object({
body: z.string(),
})
),
(c) => {
// ...
return {
..
}
}
)
But is it also possible to validate the response object returned by the handler, to eg make sure response does contain required properties, but also does not include any unwanted properties?
5 Replies
ex0ns
ex0ns11mo ago
You can do this directly in the body of the handler can't you ? Before returning c.json(content) you could call returnSchema.parse(content) (where returnSchema is a zod schema)
Marcel Overdijk
Marcel OverdijkOP11mo ago
Yes that’s an option but the same could be said for parsing the request body. I wonder if it would be possible to use a global middleware, or – even better – to have a type safe return value..
Franquito
Franquito5mo ago
I second this, were you able to do it somehow? Or is it not possible
Otaam
Otaam3w ago
I'm considering moving a project from trpc to Hono RPC and this is the only thing that is stopping me for now. With trpc my IDE will show an error if the output is not properly typed, which is a life saving feature... They are discussing it apparently : https://github.com/honojs/hono/pull/3843 https://github.com/honojs/hono/issues/2439
GitHub
feat(validator): Introduce responseValidator by EdamAme-x · Pull ...
Resolve: #2439 Related: honojs/middleware#184 This is proposal. It has not been tested, nor is it fully molded. import { Hono } from '../preset/quick' import { responseValidator } f...
GitHub
Response serialization and validation · Issue #2439 · honojs/hono
What is the feature you are proposing? Certain frameworks (eg: fastify) provide response validation for success or error payloads. Is there support for such feature in hono? If not, is it something...
ambergristle
ambergristle3w ago
hey all! hono's validator (including zod-validator, which is just a thin lib-specific wrapper) can only be used to validate requests Hono's RPC client will pick up any text or json responses returned from each handler (not middleware or onError) but if you want to ensure that the type you're returning is the type you intend to return (i.e., response validation), you have a few options in the current ecosystem - openapi integration: using the new hono/openapi lib, you can incrementally add response schemas for a variety of validation libs: https://github.com/rhinobase/hono-openapi - alternatively, you can simply parse results before returning, leveraging Hono's return type inference it really depends on your goal though if you're specifically interested in runtime response validation, parsing on demand seems sufficient if your priority is RPC type inference, you should be fine as-is. as long as your handler internals are strongly-typed, idk that there's a technical need to additionally validate the place do do runtime validation in this case is when inserting data into a db, or when data moves between layers (e.g., in constructors) if you want more baked-in type safety, such that invalid/unexpected changes to response schemas throw at compile time, hono-openapi may be the simplest path forward in terms of DX, but you can also manually type handlers, requiring a given response type manual typing can be a little cumbersome, i'd expect, but it is recommended for larger applications that are struggling with tsserver or transpilation times, so i'd call it a valid (albeit sub-optimal) solution for enforcing response types

Did you find this page helpful?