-
Notifications
You must be signed in to change notification settings - Fork 0
Open
Labels
Description
Code sample request and responses should validate against the actual API spec.
- The responses are allowed to be missing "required" properties, since code samples intentionally omit some content for brevity.
- Request and responses should validate property keys and types. If a key does not exist in the schema this is an error. And if the value does not match the expected shape, this is an error.
How to implement this? Few ideas:
- Use some existing openapi tool to validate the request / response data. As long as we can handle the "missing" response values, this seems like a good option. However, if the openapi spec is not "good enough" the validation might be too fragile.
- Since the types module exports zod types we could use those with
.parse
directly. This would work for the resources as long as we can apply a nestedpartial
to the shapes (or ignore errors about missing required keys). To handle the request body, we would need to fill out the route schemas: https://github.com/seamapi/types/blob/bfbf26dc210dffed4cb37058ab915a6fda278f47/src/lib/seam/connect/index.ts#L9-L10 - Custom validation based on the blueprint. This is guaranteed to work, but is essentially a custom implementation of a schema validator.
- Maybe this approach would work well if combined with (2). The resources all have good Zod types. While the request bodies are generally much simpler and we could generate zod types for them if they are not provided by the types module.