Over a million developers have joined DZone.

Representing Null Values in a REST JSON Response

Null vs. undefined. See how one author chooses to represent null values when dealing with REST JSON responses.

· Integration Zone

Is iPaaS solving the right problems? Not knowing the fundamental difference between iPaaS and dPaaS could cost you down the road. Brought to you in partnership with Liaison Technologies.

REST has become the de facto standard for serving data to external consumers. I have come across an interesting, but quite generic case — what do I do with attributes with null values in a JSON response. This a very basic but a very important question, and there is a lot of discussion around it with a lot of diverse opinions. Here is an aggregated analysis of how you can take care of this scenario in your own context.

For any data entity, some attributes are required and some are optional. So the question is, "What if there is no value for an optional field?" How do we represent that in our response?

A common way to handle the problem is by coding this response:

: ""(blank) or any character != null != "null" :

This basic data violation. Representing null values as any kind of string in JSON response is not right. At least, it's not intuitive for a consumer. This option is an absolute "NO." We have the following two options:

{
    "requiredField":"Some value must be here",
    "someOptionalField":null
}
//OR
{
    "requiredField":"Some value must be here",
}


Null vs. Undefined

In JavaScript, having an attribute in JSON with null and not having one (undefined) are completely different. Read more here. Consider following clauses:

Attribute with nullAttribute absent
data.someOptionalField == nulltruetrue
data.someOptionalField === nulltruefalse
data.someOptionalField === undefinedfalsetrue


If your consumer has different processing for null and undefined, then you must go with the attribute present with a null value in data (first format). Otherwise, I would suggest the second format because of one simple reason: smaller payload. This would be a big gain, especially when there are many optional fields.

There were also some arguments about readability. There are two solutions to this. One, ask the consumer to refer to the REST API documentation, which can be easily created with plenty of tools these days. Another is something I have seen with mygov.in data APIs (by the Indian government). A response contains required information from an information entity, like all attributes and their type. A second approach with a flag that omits that information would also be nice.

Basically, the decision depends on your context. If you have more suggestions please share them.

Discover the unprecedented possibilities and challenges, created by today’s fast paced data climate and why your current integration solution is not enough, brought to you in partnership with Liaison Technologies.

Topics:
rest ,json ,api design

Opinions expressed by DZone contributors are their own.

The best of DZone straight to your inbox.

SEE AN EXAMPLE
Please provide a valid email address.

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.
Subscribe

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}