NOT, I repeat NOT, I repeat NOT for verification but rather for tools, so that people working in strongly typed languages can interact with JSON services in a reasonable manner.
Unfortunately the one option I see, JSON Schema, appears to have caught the XML/Java bug, and has gotten very complicated.
JSON is so nice and easy and simple until it needs all those things that made it into XML to get the job done.
I whole heartedly agree, there is nothing sweeter than giving another vendor our WSDL with schema when they ask how to work with our system. It eliminates huge effort and ambiguity in system interaction.
SOAP, WSDL and everything else XML and XML Schema related is overkill for simple interfaces. For complex interfaces it is just - well too complex.
If the time spent creating XML based web services that kinda but not really work (we're only talking interfaces here!) is spent documenting your JSON WS - you get quite a better experience.
Ant this is the reason why everybody has switched to JSON.
JSON has no way to describe in machine readable way what to expect, instead you have to read a document then go hand code the interface in your language of choice.
WSDL and SOAP is not complicated, and I have implemented my own SOAP stack. Then again everyone now days everyone thinks relational databases are complicated.
If you you have tools that implement it for you then there is no excuse.
Out of frustration with existing schema languages and tool support for them, I've been working on Piqi[1] which is concise, expressive and agnostic to data representation formats. It works for JSON, XML and Protocol Buffers.
[1] http://piqi.org
Didn't realize you hung out on HN, so many thanks and great job.
I'd like to know more about your use case and the need for JavaScript generation. I'm open to new ideas. Could you please contact me at alavrik@piqi.org Thanks!
But the google people seem to love them, so I'm probably in the minority.
Me either! Which is why I'm working on a high-performance Protocol Buffer library that does not do code generation: https://github.com/haberman/upb/wiki
Thanks for that.
(edit: It wasn't the readme, it was the wiki page. Still, excellent documentation.)
You mean languages that lacks algebraic data types? Because JSON encodes beautifully in ML and Haskell, and their type systems are quite static and quite strong.