fluidsonic
commented
5 years ago Thank you @raderio for opening this discussion.
Here some questions and thoughts regarding your suggestion:
- What is the intended use case and benefit of having all parsing and validation issues returned at once rather than just the first one? In the majority of scenarios clients send valid JSON or are just slightly off. It is mostly during initial development of a client or because of larger API changes that a JSON structure has multiple issues. Since that is just a small minority of cases a lot of architectural overhead would have to be added in order to implement such functionality which is likely used rarely.
-
Structural validation vs. domain validation It makes sense the check for the presence and correct type of information before object creation. That is the current approach but currently needs to be done manually through
JSONCodecs. With annotation processing (#16) this would become much easier, as you've also suggested, but it's still work-in-progress and has a long way to go. Annotations would then be used to test for the correct structure and types of all information during parsing before object creation and can help with useful context-aware error messages. The result are type-safe values based on Kotlin and custom types.Domain validation like min/max, length, regex, etc. on the other hand is not just about the structure but the domain-specific traits every single property has. JSON parsing in my opinion shouldn't be about any domain-specific validation but only help transporting a data model using a defined type-safe structure from one location to another, i.e. as close to POJOs as possible. The model can then be used by domain-specific code to apply whatever rules it may deem important depending on the context the model is being used. This provides a better abstraction between data model, data (de)serialization and data validation rather than mixing up the latter two.
-
Domain validation is complex Take Twitter for example. There are complex rules involved to calculate how long a tweet actually is, including information about URL shortening and photo uploads. Calculating that length within the model or the deserialization layer for validating against the maximum length would put a lot of domain logic with a lot of dependencies in these layers. Also there may be older tweets in the database which have followed different validation rules and would no longer be valid today. They may still be valid in the model but invalid only when creating new tweets, hence it depends on the context.
Should a developer still want to perform such validation then it can easily be done directly in the constructors or initializers of model classes and completely independent of the deserialization. This allows the full use of Kotlin's extensive standard library as well as third-party (validation) libraries. Replicating validation with some special annotations will likely just reinvent part of the wheel. The overhead of implementing and maintaining such a validation system will likely outweigh the benefits by far.
- Domain validation can be done in isolation Deriving documentation from validation annotations makes sense in some simpler scenarios. Such annotation-based validation could still be implemented and applied without having to implement it directly in the JSON parser - actually completely independent of the (de)serialization library being used. Such annotations could be used by a different library to generate initializers which perform the validation and throw an appropriate exception. The (de)serialization library would then fail to create such an invalid object as intended.
- Are there any good examples of that functionality in libraries or languages which is widely used?
raderio
Usually on deserialization we want to collect all validation errors and return them in response to the client. In order to catch all error the validation should be done before object creation.
If it will be done after object creation, in
initblock, than validation will be separated in 2 phases, first one will be validation regarding non-nullable field, because we cannot create objects if they have non-nullable properties. The second one will be to do structural validation: min/max values, length, regexp pattern, etc.Example
class Data(val name: String, val age: Int, val email: String)when we send a json{"email": "xyz@xyz.com", "name": "A"}we should return a response where to indicate thatagecan not be null andnamesize must be greater than 2, at once to send all the errors.Also, structural validation will be great to do based on annotations and not in
initblock, something like JSR 303. This will be useful for documentation generation, it is far easier to generate based on annotations.How I see the flow: