Open lidel opened 2 years ago
@SgtPooki do you know which fields are often sent by services as nulls?
I propose we make this more liberal and allow null when string or array is empty.
Let's allow a string to be null if empty (null/undefined), though there is a potentially more profound argument with the semantics there.
For a property of type array, we should not allow the returning of null unless the property itself is optional. If an API spec indicates an object is supposed to be an array and required, it must always be an array, either empty or filled.
If a property of an array type is not required, we should either not return that property at all or return an empty array.
A solution that results in the most consistent shape should be best: appearing and disappearing properties are not ideal. Two solutions are poor: 1. different types (undefined/array), 2. an overloaded type(null/array).
IMHO, one solution is best: arrays should never be optional, but their contents may be.
I'll get your answer regarding null responses shortly.
For adding a pin, here is the current, rough, compliance result:
Thanks! Looks like services are really liberal in null/undefined behaviors. We have no choice but to interpret these as compliance failure for now.
In the meantime, we should see if we can allow optional fields to be nullable. Long term, it will be less work across ecosystem if we make this less strict.
We had issues where
null
value caused an error in generated client https://github.com/ipfs/go-pinning-service-http-client/issues/14.I propose we make this more liberal and allow
null
when string or array is empty. This way implementers have one less footgun to worry about.