Validating JSON with third party runtime libraries like zod is only necessary because JSON doesn't support schemas though. There's nothing wrong with those libraries, they solve a real problem but the problem is in JSON itself.

The whole point of REST was to allow visitors to not only see the response to a request but to also be able to understand both the semantics and the functionality of it.

Think HTML - it would be comparatively useless if HTML could only contain structured data with meaning, semantics, or schemas. Anchor tags, buttons, and forms are semantic and tell the user not only what a piece of text is but how they can interact with it.

With JSON you have to know the shape of requests supported, the shape of data returned, and how to use that data to make other requests.

> Validating JSON with third party runtime libraries like zod is only necessary because JSON doesn't support schemas though.

No this is completely backwards. First of all, JSON Schema exists. Second libraries like Serde and Pydantic aren't schema validators; they are parsers. They parse strings (or sometimes dynamically typed JSON) into statically typed objects that you can actually use in your program. That's what you should use.

A program that uses a separate schema validator and then blindly trusts the result is badly designed. There's even a name for this mistake - "parse don't validate" (you can Google it).

> With JSON you have to know the shape of requests supported, the shape of data returned, and how to use that data to make other requests.

Obviously. XML doesn't magically avoid the need for API documentation! I'm wondering if you've ever actually used XML at this point....