Slightly off-topic, but yes, having fail-fast deserialisation is great.
I wrote a json/kotlin-serialisation library once and purposely restricted some json-features to achieve that:
1. Fields can arrive in any order - this is standard
2. Field names are matched case-insensitively - so keyA and keya are the same, because who would use two variables differing only by case. Serialization keeps the original casing of the name.
3. Missing fields throw an error. if they are nullable, they have to be explicitly set to null - so that you can be sure the serialization side upgraded to the latest version of a protocol if a field was added, and things don't just work by chance.
4. Nullable strings are not coerced to empty strings or anything like it. Kotlin is null-safe, so if it's a string, it has to be "". If it's, for whatever reason, a nullable string, you can set it to null.
5. Enums are also serialized case-insensitively - so you an write "keyA": "eNumVaLuE" if you want - typos should not break the code here, no on would you two enums differing only by case. IIRC booleans could also be TRUE, tRuE, truE etc. (but NOT t or f, or yes or no, or 0 or 1 or empty).
6. Superfluous properties are silently ignored.
These rules were a great tradeoff for quick development, mixing languages and having fail-fast behavior with a stable protocol.
I wrote a json/kotlin-serialisation library once and purposely restricted some json-features to achieve that:
1. Fields can arrive in any order - this is standard
2. Field names are matched case-insensitively - so keyA and keya are the same, because who would use two variables differing only by case. Serialization keeps the original casing of the name.
3. Missing fields throw an error. if they are nullable, they have to be explicitly set to null - so that you can be sure the serialization side upgraded to the latest version of a protocol if a field was added, and things don't just work by chance.
4. Nullable strings are not coerced to empty strings or anything like it. Kotlin is null-safe, so if it's a string, it has to be "". If it's, for whatever reason, a nullable string, you can set it to null.
5. Enums are also serialized case-insensitively - so you an write "keyA": "eNumVaLuE" if you want - typos should not break the code here, no on would you two enums differing only by case. IIRC booleans could also be TRUE, tRuE, truE etc. (but NOT t or f, or yes or no, or 0 or 1 or empty).
6. Superfluous properties are silently ignored.
These rules were a great tradeoff for quick development, mixing languages and having fail-fast behavior with a stable protocol.
(https://medium.com/@fabianzeindl/generated-json-serialisatio...)