91
votes

I'm creating an API that returns results as JSON. Is there a current best practice for whether we should include keys in the result when the value is null? For example:

{
    "title":"Foo Bar",
    "author":"Joe Blow",
    "isbn":null
}

or

{
    "title":"Foo Bar",
    "author":"Joe Blow"
}

Since the second is smaller I am leaning towards this style, but I'm not sure if there is a preferred style or not. From a client perspective it seems like both styles would be functionally equivalent. Any pros or cons to each?

5
It is impossible to answer this correctly. The correct answer depends on the requirements of the application. The OP has simply selected the answer that suits his requirements. If your application needs to be able to distinguish between knowing if the "isbn" is null vs if the "isbn" may not have been sent from the server for another reason, you need to include it. - Jay
@Jacob Although I didn't say it, my intention with this question was that the "full" JSON representing the response was being returned. When a client can assume that there seems to be no functional difference between the two approaches. If the API would selectively not return keys/values then yes it would make a big difference which approach was taken. - jjathman
the benefit of the first representation is that the object schema is preserved, the presence of the property is not ambiguous based on data. in the second format this information is lost. JSON spec as such does not mandate either format AFAIK - Surya Pratap
I think there's nothing opinionated about this question. JSON is a standard. There should be a specification for it, and probably a bunch of RFC's. // On top of that, even opinionated questions can be acceptable. There have been discussions about this before on meta.stackexchange where they ruled that opinionated questions are fine from a point of sharing "best practices". - bvdb

5 Answers

32
votes

The second will save a small amount on bandwidth, but if that were a concern you would also use indexed arrays instead of filling the JSON with keys. Clearly, ["Foo Bar","Joe Blow"] is much shorter than what you have now.

In terms of usability, I don't think it makes any difference. In both cases, if(json.isbn) will skip to the else. There is usually no need to distinguish between null (no value) and undefined (no given value).

82
votes

I am a fan of always including null explicitly as that carries meaning. While omitting a property leaves ambiguity.

As long as your protocol with the server is agreed upon any of the above can work, but if you pass nulls from the server I believe that makes your APIs more flexible later.

Should also mention that javascript's hasOwnProperty function gives you further insight.

/* if true object DOES contain the property with *some* value */
if( objectFromJSON.hasOwnProperty( "propertyName" ) )

/* if true object DOES contain the property and it has been set to null */
if( jsonObject.propertyName === null )

/* if true object either DOES NOT contain the property
   OR
   object DOES contain the property and it has been set to undefined */
if( jsonObject.propertyName === undefined )
22
votes

In JavaScript, null means something very different than undefined.

Your JSON output should reflect what is used and needed by your application in the specific context of using the JSON data.

12
votes

You should definitely include it if there is any need to distinguish between null and undefined since those have two different meanings in Javascript. You can think of null as meaning the property is unknown or meaningless, and undefined as meaning the property doesn't exist.

On the other hand, if there is no need for anyone to make that distinction then go ahead and leave it out.

1
votes

When JSON is used as API data carrier, there is no difference if there is a null or empty (undefined) value. Probably, the empty is better because we save some payload size.

The difference appears for JSON-config files when you would like to edit something by hands. It is better to have nulls there instead of undefined props. This way you will give hints about the config props existence.