Many people would need additional tooling to parse JSON into a structured type, especially in dynamic languages where unstructured data types are the norm. And even if you do that, you're still going to have to validate the data and tell the client where they might have messed up the formatting.
Parsing is a totally fine, low-cost, low-risk way to validate chunks of JSON before trying to parse them -- or not trying to parse them, if that's your choice. People who use TypeScript on the server side, for example, will only need to validate.
> Many people would need additional tooling to parse JSON into a structured type, especially in dynamic languages where unstructured data types are the norm.
Well, there's your first issue. Specifying your formats is a good idea, regardless of language. And this is completely possible in dynamic languages too, see for example Python's Marshmallow.[0]
> And even if you do that, you're still going to have to validate the data and tell the client where they might have messed up the formatting.
The point is that you should take the opportunity to encode this validation in your types. A validated email address is no longer a `String`, it's an `Email`, with different valid operations. Or for an extreme example, you (hopefully) wouldn't try do time calculations directly on RFC 3339 strings.
This doesn't have to happen at exactly the same time as parsing the JSON AST, it's completely sensible to go JSON -> JSON AST -> Model.
OK, I understand what you're saying. OpenAPI can be used for what you're describing. I just don't really understand the false dichotomy between validation and parsing. OpenAPI can be used for both depending on the language, and if you're writing docs, you might as well write them in OpenAPI format and get a validator for free.
There is a difference between the common meaning of parsing (text -> (ast | error)) and the generalized meaning that Alexis uses in the post (less structured -> (more structured | error)).
