Closed maxheld83 closed 3 years ago
Thanks for the write up and for some background information on why null
or empty arrays would help out in this case.
I talked to some of the team and it seems as a general principle we never use null
and use an empty array for optional values. We did find some examples inconsistent with this general principle, but that's the approach we're taking for now.
As mentioned in some other issues (like #549), we don't have any documentation as to why these decisions were originally made, and the folks who worked on the REST API at the time aren't around anymore. We may end up revisiting how we handle null
vs empty arrays vs missing objects sometime down the line, but for now we are working on other aspects of the API, most importantly, the previously mentioned Elasticsearch migration.
I'm staring from the assumption that it's desirable for an API to show
null
(or empty arrays) for empty fields. For our use case, this would enable length-stability in our api and production code, which we're currently lacking.If I'm missing a central tenet of crossref data, or just being boneheaded stop me right here.
Such "length stability" also seems to be considered a best practice by some:
This appears not to be the case for the Crossref REST API.
For illustration:
http://api.crossref.org/works/10.1038/s41598-020-57429-5
includes:http://api.crossref.org/works/10.1109/JLT.2019.2961931
, in the same place, only includes:The later is missing the
license
field. As per the above, there should be an empty array in it's place, like so: