3 ms·
My experience is that strictness is preferable here; silently accepting bad keys in a JSON object will lead the caller to think it's working, when it's not. If
by lobster_johnson 9y ago
My experience is that strictness is preferable here; silently accepting bad keys in a JSON object will lead the caller to think it's working, when it's not.
If you then break the API's backwards compatibility by, say, removing a field, then your API will visibly break, which is correct, something you'd otherwise not detect.
The solution to maintaining backwards compatibility is a combination of explicit versioning, erroring like this, good documentation, and trying to support old features for as long as possible.
Definitely never liked Go's silent ignoring of JSON keys. The workarounds (e.g. overriding the unmarshal code to apply a check) have always been very invasive.
Edit: Maybe you meant in the client, since you wrote "against". If so, I would still argue that strictness is good, as you do want your client to break (or at least warn) if something changes.
- bpicolo 9y ago> If you then break the API's backwards compatibility by, say, removing a field, then your API will visibly break That's a different issue. Fields going missing is definitely something I want to cause big problems. I do mean consumers (e.g. unmarshalling JSON responses from APIs), as the typical mechanism to support backwards compatibility is by adding keys. Otherwise you can't upgrade ever without entirely new API versions, and you force lockstep for deployments. Needing new data is a common thing - maybe you have user endpoint that's not returning <some_flag> that you added that you now want in some new service. Bumping APIs for every added field would get unwieldy fast and you'll have services scattered among many API 'versions'. It's just like in protobuf. In protobuf (or most other service-to-service serialization libs), adding a new field is not backwards incompatible.