Proposal: encoding/json: Add Support of Simple Validation Tags #16426
Comments
|
I don't understand why this needs to be done in encoding/json; surely you could walk the decoded struct and perform the same validation separately with a different package, no? |
|
I don't think we should put any forms of verification built-in in My counterproposal: However, we need to be careful not to make existing types accidentally This also somewhat related to the recent node-level error message issue |
|
Any interest in the encoding.Validator interface? I could write a formal
proposal if there are enough interest.
My current thought looks like this:
type Location int64 // byte offset
type Validator interface {
// Validate validates the object, begin and end is the half-open
interval for the stream occupied by this object.
Validate(begin, end Location) error
}
Using a special type avoid existing Validate funcs accidentally implement
the new interface.
We might need a better name because Validate might already be used widely.
If an object implements Validator interface, then its Validate method will
be called after it's unmarshaled.
|
|
Thanks for your timely response!
No, it is not possible in some situations without decoding the data twice. For instance, how do you perform the required/noExtraFields validation by walking the decoded struct?
Although the encoding.Validator interface you suggested does not mean the same thing, it does provide new thoughts to solve similar problems, and gives more flexcibility. I support you. Please go ahead with a new proposal! Back to the proposal I suggested, if it cannot be accepted, I will make an implementation in a separate package. I believe that more people will benefit from it. |
|
I'm all for expanded JSON specification reduction utility in these tags that are already not that intuitive. Seems like a decent place to add validations since the encoding/json package already has to inspect and reflect on the entire encoded string's data. Although a more pure and simple JSON package in the standard library, along with an information and validation companion package, could make sense. |
|
This is a potentially very large change; the schema document is almost as long as the whole Go spec. It makes more sense to do this in an external JSON package, not in the Go core libraries. |
Abstract
This document proposes to support simple validation tags in the encoding/json module.
Background
It's very common for the 2 ends, which communicate in JSON, to validate the received data before processing it. Current approaches include making the validation by introducing a schema validation package or making an in-line validation. Either solution has its shortcomings. A schema validation package seems too heavy for a JSON message containing only simple validations and is not efficient because it causes an extra decoding cycle of the message. An in-line validation will need extra efforts to maintain when the message structure changes.
Proposal
Simple validations can be specified in the tags of corresponding Go's struct. When json.Unmarshal is called to decode the data, these tags will be considered and the data passed in will be checked against them. If one of the validations fails, json.Unmarshal will return with an error describing this situation.
For instance, given the Go struct:
only a JSON object with a type field, which is of integer type and has a value between 1 and 3, and an optional content field, which is of string type and has a value containing 5 to 20 characters, can pass the validation.
Suggested tags are:
Impact
The proposal won't break current behaviours. It only has little performance penalty and the implementation will be a little bit complex. It will also bring in package dependency to the regexp package if the pattern or format tag is supported.
References
JSON Schema Validation
The text was updated successfully, but these errors were encountered: