4 ms·
Any time two different teams (or even people) are writing code that talk to common JSON, it's probably a good idea to define it in a schema. Think of it as a cl
by andreyf 17y ago
Any time two different teams (or even people) are writing code that talk to common JSON, it's probably a good idea to define it in a schema. Think of it as a class of unit tests - except the relative effort required is miniscule, and the benefits exactly the same.
- mbreese 17y agoI can understand the desire to do define the formats, but this (Orderly) is bordering on ridiculous. You create a new microlanguage that compiles to a different microlanguage which is a DSL in the same language that your objects are stored in, so that it can be validated to be read properly in yet another language (unless your main code in already in Javascript). This just strikes me as a step down the path of WS-* or similar XML nonsense. What ever happened to just having a README or documentation that just says what the fields in the object are? Why does it need to be validated by a different tool/language?
- andreyf 17y agoSure you have a README and documentation. I once worked on a system which had a ProjectName-JSON-spec-verion-3.5a.doc of >200 pages being e-mailed back and forth between a "back-end team" in India, and a "front-end team" in New York.