Standard in json's answer

[patricksan]

We need to standardize the json's answer for endpoint /photos/list.json

Example 1:

"description":null

// example
"title":null,"description":null

Example 2:

"description":""

// example. Is this related to title != null ?
"title":"Sunn middag","description":""

I would prefer an empty string than null for json's answers.

[jmathai]

As I look at this issue more I think having null values makes sense. It differentiates between an entry not being set versus being set as an empty string.

We do have keys which should be integers but are strings. In theory they should be INT fields but pragmatically I think having everything as a string might be easier. As a developer (specifically when using loosely typed languages like PHP or JavaScript) it is easier to know that everything is a string and to convert it as needed than wonder and have to look up documentation on if the dateYearTaken value is an int or not.

Not closing this but postponing fixing this. If we do fix it then I think it should be part of changes that increase the API version #.

[patricksan]

Agree, but entities with empty string should return null instead of "". So we need to check if user type empty values ("") and replace by null.

[jmathai]

But then you're back to not being able to differentiate if a call to a POST api was made by passing in the parameter. I concede that it might not be valuable to be able to tell...in which case we should just return empty strings like your original suggestion (I think).

[jmathai]

I think having the ability to know if the parameter was ever set (empty or populated string) versus never having passed in.