Validate response objects
Using the zod validator middleware it is possible to validate params , query, request body like:
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
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)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..
I second this, were you able to do it somehow? Or is it not possible
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...
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