Skip to content

Responses from API calls using the Accept header application/vnd.nasa.pds.pds4+json contain inconsistent field types. #754

@anilnatha

Description

@anilnatha

Checked for duplicates

No - I haven't checked

🐛 Describe the bug

I've been reviewing the structured JSON response from the API and have a concern about the types being used in the response. I noticed some fields are being returned as different types in some cases. Let me explain using the External_Reference field as an example. During a cursory review I found that the Internal_Reference and Alias fields are also experiencing the same behavior I'm about to describe, and there could be others.

Sometimes the External_Reference field is set to an object literal, probably because only one external reference exists in the archive for a given record, e.g. for urn:nasa:pds:context:instrument:guelph-wel.guelph_wt::1.3:

"External_Reference": {
	"reference_text": "Nickling, W.G., and M. Ecclestone, (1981), The effects of soluble salts on the threshold shear velocity\n
of fine sand, Sedimentology, 28(4):505-510.",
	"doi": "10.1111/j.1365-3091.1981.tb01698.x"
},

Sometimes it's set to an array since multiple "external references" exist, e.g. for urn:nasa:pds:context:instrument:ksu-hpwel.chepil_wt::1.2:

"External_Reference": [
	{
		"reference_text": "Chepil, W.S. (1959) Equilibrium of Soil Grains at the Threshold of Movement by Wind, Soil Science Society\n     
of America Journal, 23(6): 422-428.",
		"doi": "10.2136/sssaj1959.03615995002300060019x"
	},
	{
		"reference_text": "Zingg, A. and W.S. Chepil, (1950), Aerodynamics of Wind Erosion, Agr. En., Vol.31, June 1950, pp. 279-282, 284."
	}
],

Thomas and I didn't know if we should log this as a feature request or a bug, so I just added it as a bug.

🕵️ Expected behavior

I consider this a bad practice and after checking with AI it seems to agree (see screenshots). It would be very helpful if in the first case the field was set to an array with only one element as opposed to being set as an object literal. Having to code for different types for the same field will mean every API user, ourselves included, will have to handle the different types, making it more difficult to maintain and test.

Image Image

📜 To Reproduce

...

🖥 Environment Info

  • Version of this software [e.g. vX.Y.Z]
  • Operating System: [e.g. MacOSX with Docker Desktop vX.Y]
    ...

📚 Version of Software Used

No response

🩺 Test Data / Additional context

No response

🦄 Related requirements

🦄 #xyz

⚙️ Engineering Details

No response

🎉 Integration & Test

No response

Metadata

Metadata

Labels

Type

No fields configured for Bug.

Projects

Status

ToDo

Status

Todo

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions