You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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 init block, 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 that age can not be null and name size 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 init block, something like JSR 303.
This will be useful for documentation generation, it is far easier to generate based on annotations.
The text was updated successfully, but these errors were encountered:
Hm, with this flow I think it is possible to create a validation framework on top of kotlinx.serialization, because it provides both converters: json -> json tree and json tree -> object (see JsonTreeParser and JsonTreeMapper).
The Json in serialization itself does direct mapping without intermediate tree
For my understanding, validation and deserialization should be provided by same library, because deserialization module decides to which class to deserialize, in case of polymorphism for sure.
But validation should be done before desrilization, but to do validation we should know to which class will be done deserialization.
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
init
block, 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 thatage
can not be null andname
size 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
init
block, something like JSR 303.This will be useful for documentation generation, it is far easier to generate based on annotations.
The text was updated successfully, but these errors were encountered: