-
Notifications
You must be signed in to change notification settings - Fork 27
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow nulls #89
Comments
@SgtPooki do you know which fields are often sent by services as nulls? |
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: Click to expandhttps://api.pinata.cloud/psa compliance:api.pinata.cloud: Rate limit is 180 and we have 179 tokens remaining. Can pin a self-identifying CID - ✓ SUCCESShttps://api.estuary.tech/pinning compliance:Can pin a self-identifying CID - ✘ FAILEDExpectationsDetailsRequest - POST: https://api.estuary.tech/pinning/pinsHeaders
Body
Response data from https://api.estuary.tech/pinning/pinsvia util.inspect
Response data after being parsed by RemotePinningServiceClientvia util.inspect
Joi validation failures
Response - Accepted (202)Headers
Body
https://nft.storage/api compliance:Can pin a self-identifying CID - ✘ FAILEDExpectationsDetailsRequest - POST: https://nft.storage/api/pinsHeaders
Body
Response data from https://nft.storage/api/pinsvia util.inspect
Response data after being parsed by RemotePinningServiceClientvia util.inspect
Joi validation failures
Response - OK (200)Headers
Body
https://api.web3.storage compliance:Can pin a self-identifying CID - ✘ FAILEDExpectationsDetailsRequest - POST: https://api.web3.storage/pinsHeaders
Body
Response data from https://api.web3.storage/pinsvia util.inspect
Response data after being parsed by RemotePinningServiceClientvia util.inspect
Joi validation failures
Response - Accepted (202)Headers
Body
|
Thanks! Looks like services are really liberal in null/undefined behaviors. In the meantime, we should see if we can allow optional fields to be nullable.
|
We had issues where
null
value caused an error in generated client ipfs/go-pinning-service-http-client#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.
The text was updated successfully, but these errors were encountered: