3 ms·

In the face of good information I'm always willing to change my mind. Should we enforce valid JSON? This seems like a lot to ask of front-end devs that will be

In the face of good information I'm always willing to change my mind. Should we enforce valid JSON? This seems like a lot to ask of front-end devs that will be using our templates. For what it's worth, Kris on our team is very pro-JSON validity.

thwarted 16y ago
If frontend devs can produce valid HTML, they can produce valid JSON. They aren't idiots. Be strict in what you produce and liberal in what you accept is nice and all, but that's how we got into the mess that is different implementations of HTML and "quirks mode" in different browsers today.
- JoelSutherland 16y ago
  See my other comment about this not being an API level decision. At the template level and JS library level we're not doing any magic. Javascript allows keys of object literals to be written without quotes when they aren't reserved. We didn't implement a layer on top of Javascript enforcing otherwise. There is nothing controversial about this.
  - thwarted 16y ago
    At the template level and JS library level we're not doing any magic. Javascript allows keys of object literals to be written without quotes Javascript does, but the JSON standard does not. Both on the root page of JSON.org and in sections 2.2 and 2.5 of RFC4627, JSON object member's keys are strings, and strings are defined as delimited by double quotes. It's pretty explicitly defined in the RFC. So while you can say that your structure is Javascript code, you can't really say it's JSON. Saying it is JSON but not following the JSON standard only leads to confusion and failures when people try to parse it with JSON parsers rather than unsafely evaluating it with a Javascript interpreter. And no one should be encouraging the use of javascript eval to unserialize JSON due to security concerns.
    - JoelSutherland 16y ago
      The API is JSON. It only accepts valid JSON and it returns valid JSON. Library != API
aaronblohowiak 16y ago
I'd warn on invalid JSON if that is possible. I don't go as far as Thwarted and say you should forbid invalid JSON, but we're now talking about application behavior and not example code. I try to have very high test coverage and code comments in the libraries I publish, but only "reasonable" coverage and almost no comments in the application code that I produce (unless what I am writing is in some way "weird.")
jerf 16y ago
If it doesn't conform to the grammar at json.org, don't call it JSON, because it's not. You're free to take something more loose or something more strict, but you should call a spade a spade. If your API accepts "<x><y></x></y>", you are free to do that, but you should not then say that your API is "XML". XML-ish, an "XML superset", sure, but you shouldn't devalue the word. And if you're careful and know what you are doing there is no harm. You'd be surprised where the harm can come from if you are not careful or don't know what you are doing. My general advice is that serialization is about ten times harder than it looks to really, really get right on the Internet scale, and when it breaks it tends to break unfixably (that is, "irrecoverable data loss", though even just realizing you've triggered that condition can be a challenge), and the easiest thing to do is rigidly use an existing format. But you can always do whatever you like; I'll only stand on requesting that you use rigidly-specified terminology correctly. (And I did say "requesting".)
- JoelSutherland 16y ago
  The API does not accept invalid JSON. The JS Library will take object literals. It uses JSON.stringify internally. The templating language takes object literals.
  - jerf 16y ago
    OK, sounds good. There's no reason for JS to internally take strict JSON when it's already JSON. I say that not because I'm accusing you of it, but because I've seen the moral equivalent, only done with XML and communicating between two functions in the same process space with no RPC exposure.... :)

thwarted 16y ago

If frontend devs can produce valid HTML, they can produce valid JSON. They aren't idiots. Be strict in what you produce and liberal in what you accept is nice and all, but that's how we got into the mess that is different implementations of HTML and "quirks mode" in different browsers today.

JoelSutherland 16y ago
See my other comment about this not being an API level decision. At the template level and JS library level we're not doing any magic. Javascript allows keys of object literals to be written without quotes when they aren't reserved. We didn't implement a layer on top of Javascript enforcing otherwise. There is nothing controversial about this.
- thwarted 16y ago
  At the template level and JS library level we're not doing any magic. Javascript allows keys of object literals to be written without quotes Javascript does, but the JSON standard does not. Both on the root page of JSON.org and in sections 2.2 and 2.5 of RFC4627, JSON object member's keys are strings, and strings are defined as delimited by double quotes. It's pretty explicitly defined in the RFC. So while you can say that your structure is Javascript code, you can't really say it's JSON. Saying it is JSON but not following the JSON standard only leads to confusion and failures when people try to parse it with JSON parsers rather than unsafely evaluating it with a Javascript interpreter. And no one should be encouraging the use of javascript eval to unserialize JSON due to security concerns.
  - JoelSutherland 16y ago
    The API is JSON. It only accepts valid JSON and it returns valid JSON. Library != API

aaronblohowiak 16y ago

I'd warn on invalid JSON if that is possible. I don't go as far as Thwarted and say you should forbid invalid JSON, but we're now talking about application behavior and not example code. I try to have very high test coverage and code comments in the libraries I publish, but only "reasonable" coverage and almost no comments in the application code that I produce (unless what I am writing is in some way "weird.")

jerf 16y ago

If it doesn't conform to the grammar at json.org, don't call it JSON, because it's not. You're free to take something more loose or something more strict, but you should call a spade a spade. If your API accepts "<x><y></x></y>", you are free to do that, but you should not then say that your API is "XML". XML-ish, an "XML superset", sure, but you shouldn't devalue the word. And if you're careful and know what you are doing there is no harm. You'd be surprised where the harm can come from if you are not careful or don't know what you are doing. My general advice is that serialization is about ten times harder than it looks to really, really get right on the Internet scale, and when it breaks it tends to break unfixably (that is, "irrecoverable data loss", though even just realizing you've triggered that condition can be a challenge), and the easiest thing to do is rigidly use an existing format. But you can always do whatever you like; I'll only stand on requesting that you use rigidly-specified terminology correctly. (And I did say "requesting".)

JoelSutherland 16y ago
The API does not accept invalid JSON. The JS Library will take object literals. It uses JSON.stringify internally. The templating language takes object literals.
- jerf 16y ago
  OK, sounds good. There's no reason for JS to internally take strict JSON when it's already JSON. I say that not because I'm accusing you of it, but because I've seen the moral equivalent, only done with XML and communicating between two functions in the same process space with no RPC exposure.... :)