views:

409

answers:

7

Part of a website's JSON response had this (... added for context):

{..., now:function(){return(new Date).getTime()}, ...}

Is adding anonymous functions to JSON valid? I would expect each time you access 'time' to return a different value.

+1  A: 

It is not standard as far as I know. A quick look at http://json.org/ confirms this.

jldupont
+1  A: 

JSON explicitly excludes functions because it isn't meant to be a JavaScript-only data structure (despite the JS in the name).

Tatu Ulmanen
+8  A: 

JSON is purely meant to be a data description language. Per http://www.json.org, it is a "lightweight data-interchange format." - not a programming language.

Per http://en.wikipedia.org/wiki/JSON, the "basic types" supported are:

  • Number (integer, real, or floating point)
  • String (double-quoted Unicode with backslash escaping)
  • Boolean (true and false)
  • Array (an ordered sequence of values, comma-separated and enclosed in square brackets)
  • Object (collection of key:value pairs, comma-separated and enclosed in curly braces)
  • null
Mike
Is [], {} equal to null? I know nothing is comparable to null, including null, but is an empty set evaluated as a null value?
Dr. Zim
A: 

Only as a callback, I believe. Most server-side APIs offer support for specifying the callback function in the URL. http://developer.yahoo.com/common/json.html#callbackparam

But not as a value, or within the data.

What's with the downvotes?

Computer Linguist
I didn't downvote, but I would wager it is because your answer is not relevant to the question. The callback you are referring to is a way to automatically execute a local function with the remote JSON as its parameter, the question is referring to whether or not it is OK to treat JSON as an actual javascript object with respect to embedded methods.
jsoverson
Yeah, I suppose more detail on why any other use of functions is prohibited would have been a good idea.
Computer Linguist
+1  A: 

Nope, definitely not.

If you use a decent JSON serializer, it won't let you serialize a function like that. It's a valid OBJECT, but not valid JSON. Whatever that website's intent, it's not sending valid JSON.

jvenema
I use JSON-Lib and consider it to be a great serializer. From the [usage page](json-lib.sourceforge.net/usage.html) you can see it will serialize functions just fine
harschware
Interesting...I've never seen that before. It's definitely not to spec (http://www.json.org/ explicitly states that JSON is language independent, which function definitions are not), but interesting nonetheless.
jvenema
+1  A: 

The problem is that JSON as a data definition language evolved out of JSON as a JavaScript Object Notation. Since Javascript supports eval on JSON, it is legitimate to put JSON code inside JSON (in that use-case). If you're using JSON to pass data remotely, then I would say it is bad practice to put methods in the JSON because you may not have modeled your client-server interaction well. And, further, when wishing to use JSON as a data description language I would say you could get yourself into trouble by embedding methods because some JSON parsers were written with only data description in mind and may not support method definitions in the structure.

Wikipedia JSON entry makes a good case for not including methods in JSON, citing security concerns:

Unless you absolutely trust the source of the text, and you have a need to parse and accept text that is not strictly JSON compliant, you should avoid eval() and use JSON.parse() or another JSON specific parser instead. A JSON parser will recognize only JSON text and will reject other text, which could contain malevolent JavaScript. In browsers that provide native JSON support, JSON parsers are also much faster than eval. It is expected that native JSON support will be included in the next ECMAScript standard.

harschware
A: 

I would also like to know if there is any other reason not to put functions in JSON. It is not "valid JSON" in the sense of a data definition, but I see no reason to neuter my own JSON just because there was a standard based on it. I use functions in remote JSON requests because, to me, it is an organized, modular way of delivering data with it's associated methods. In the event that I must deal with a 3rd party server, I'll standardize. Is there any technical or security reason not to do this if it validates on all browsers and if the server authenticates each JSON call?

webnician