[Nullabillity]

> 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.

[0]: https://marshmallow.readthedocs.io/en/stable/

[smt88]

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.