Hacker News Reader

Comment by JoelSutherland | Hacker News Reader

We use valid JSON in our documentation.

Personally, I don't have a problem using invalid JSON in some places. For example, our templates.

It saves keystrokes and will never cause problems since we're not evaluating those as Javascript anyway. I do understand that reasonable people would disagree with this position however.

edit:

It isn't clear here that I am not talking about our API or JSON really for that matter.

The API requires valid JSON.

But just as jQuery translates an object literal in it's AJAX call, our JS library (not API!) translates object literals to valid JSON before sending it to the API. Object literals are not JSON.

For clarity we've edited the original post.

View on HN

will never cause problems since we're not evaluating those as Javascript anyway

A lot of JSON libraries, e.g. json_decode in PHP, refuse to parse JSON without double-quoted keys. I'm actually curious what you are using to parse it (that isn't running on JavaScript) that allows such things. I don't know the details of your API, but is this an object that you intended to be passed to a jQuery method that re-encodes it with JSON.stringify before sending it to your API?

In face of the downvotes, I should clarify that this isn't a decision at the API level! The API requires JSON, valid JSON, of course.

The templates operate against the API, delivering it valid JSON. Just like you can write an object literal in Javascript without quoted strings, you can in our templates as well.

The JS library uses JSON.stringify before sending it to the API.

The depth of my preference to omit quotes on keys when allowed extends no deeper than this blog post. I am sure Kris will regret having me format it for him.

IMHO, framework/library examples should be viewed as instruction as much as they are documentation. It helps to increase the understanding of junior devs.

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.

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.

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.

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.

The API is JSON. It only accepts valid JSON and it returns valid JSON.

Library != API

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

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

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.

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

Reply on news.ycombinator.com