json field with no value - omit or pass null?

[Andrew B]

In my application/json API, when I GET a resource has no value for the field "foo", which of these is "more correct"?

{

"foo": null

}

vs.

{

}

And would it be best practice for clients to treat both as equivalent? 

Considerations

--------------

- the first is the default for Jackson at least (can be overridden with the @JsonInclude annotation)

- the second is more efficient on the wire

- only allowing the second allows the json schema to be more expressive and enforce foo being present:

{

 "$schema": "http://json-schema.org/draft-04/schema#",

 "type": "object",

 "properties": {

   "foo": {

     "type": "string"

   }

 },

 "required": [

   "foo",

 ]

} 

[Peter Monks]

G’day Andrew,

No concrete answers here, just my $0.02 worth...

In a previous life we chose to elide value-less fields (the 2nd option, below), and (tried to) avoid the use of null altogether.  We also explored eliding empty arrays and maps, but in the end we ran into some corner cases where we were forced to keep both empty arrays / maps and null.  It’s been some years so I don’t quite recall all the specifics, but with enough thought I’m fairly certain most of those corner cases could be figured out.

While I am philosophically a fan of this model (to me it’s another instance of Tony Hoare’s “Billion Dollar Mistake”), it’s hard to know whether the benefits (in terms of over-the-wire weight and parsing-costs, especially on mobile devices) outweighs the potential for added complexity in the client application.

Cheers,

Peter

--
You received this message because you are subscribed to the Google Groups "API Craft" group.
To unsubscribe from this group and stop receiving emails from it, send an email to api-craft+...@googlegroups.com.
Visit this group at https://groups.google.com/group/api-craft.
For more options, visit https://groups.google.com/d/optout.

[James Nail]

Also nothing concrete here, but I had to make the same decision just the other day when defining an element in our  existing JSON schema.

The deciding factor for me was that JSON schema (which I don't know particularly deeply) treats null as a type violation, but doesn't make it easy to treat nulls the same as a missing field.

I ended up just dictating that the field just be excluded from the JSON document.  I would've preferred to just allow the nulls, but yeah, thanks JSON schema. :-P

[Pete Johanson]

My SO answer to this, which summarizes a previous discussion here:

http://stackoverflow.com/q/15686995/131887

-pete

[Doug Orleans]

FWIW, I think you can allow nulls in a JSON schema using "anyOf" (the type union operator):

{
  "anyOf": [
    { "type": "string" },
    { "type": "null" }
  ]
}

[sune jakobsson]

This kind of boils down to how "advanced" the client is, often clients only look for a field in a JSON response, and don't care too much about any validation, or object instantiation. 

Hence that kind of client would be faster if there is noting inside the JSON. 

And there is really nothing mentioned in the standard: http://www.ecma-international.org/publications/files/ECMA-ST/ECMA-404.pdf 

Sune

[Andrew B]

Thanks Peter and to everyone for the input. We will probably go with eliding the empty values but it seems like there's no single correct answer. Great outcome though to learn about Tony Hoare's billion dollar mistake!

(BTW this adds nothing of value to the discussion but I came across Null Island for the first time somehow in my googling for this: http://www.vicchi.org/2014/04/05/welcome-to-the-republic-of-null-island/)

Cheers,

Andrew