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.
Join the DZone community and get the full member experience.
Join For FreeREST 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 null | Attribute absent | |
---|---|---|
data.someOptionalField == null | true | true |
data.someOptionalField === null | true | false |
data.someOptionalField === undefined | false | true |
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.
Opinions expressed by DZone contributors are their own.
Comments