Schema — Parse, Don't Validate
Data enters your program from the outside world: HTTP request bodies, database rows, configuration files, message queue payloads. All of it is untrusted. All of it needs to be checked.
The naive approach is to deserialise first and validate later — accept a User struct via serde, then check that email is non-empty and age is positive in a separate step. The problem: your type says User but your program has a User that might have an empty email. The type lies.
The better approach is parse, don't validate: transform untrusted input into trusted types in one step. If the parse succeeds, you have a valid User. If it fails, you have a structured ParseError that tells you exactly what was wrong.
id_effect's schema module is built on this principle.
What This Chapter Covers
Unknown— the type for unvalidated wire data (next section)- Schema combinators — the building blocks for describing data shapes (ch14-02)
- Validation and refinement —
refine,filter, andBrandfor domain constraints (ch14-03) ParseErrors— structured, accumulating error reports (ch14-04)