Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Representing Null Values in a REST JSON Response

DZone's Guide to

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
Free Resource

Modernize your application architectures with microservices and APIs with best practices from this free virtual summit series. Brought to you in partnership with CA 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 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.

The Integration Zone is proudly sponsored by CA Technologies. Learn from expert microservices and API presentations at the Modernizing Application Architectures Virtual Summit Series.

Topics:
rest ,json ,api design

Opinions expressed by DZone contributors are their own.

THE DZONE NEWSLETTER

Dev Resources & Solutions Straight to Your Inbox

Thanks for subscribing!

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

X

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

{{ parent.tldr }}

{{ parent.urlSource.name }}