Struct / Payload validation and error formatting

[asdine]

I believe payload validation is a pretty common task when writing HTTP/gRPC servers (and others). While existing libraries allow us to validate pretty much anything, by experience it's very complicated to customize them so they can return errors that can be formatted the way we want. (Not sure if you are expecting this kind of issues so i apologize in advance if it's not relevant.)

[bketelsen]

Perfectly relevant @asdine. Do you have code you want to contribute, or do you want to have this be a suggestion for a requested package?

[asdine]

I have explored a few solutions, one of them is a small layer that i wrote on top of https://github.com/asaskevich/govalidator. I'm not particularly attached to this solution but i believe it's a lead. Having an API that allows us to exploit, update and display these errors in an unified way would be a cool thing. I'd be glad to contribute on this topic once we reach a consensus.

[bketelsen]

That's awesome, I love and use govalidator frequently. @markbates is there a validator in buffalo? Having a well designed validation solution benefits many.

[markbates]

Buffalo and Pop both use https://github.com/markbates/validate. You have to write code, instead of struct tags, but, personally, I prefer that. Code compiles and is testable, struct tags aren't. The interface for new validators is pretty straightforward:

type Validator interface {
    IsValid(errors *Errors)
}

There are a lot of great methods, such as HasAny, Count, etc... plus errors marshal nicely into JSON and XML.

With that said, not offended if it's not chosen. Just throwing it out there.

[bketelsen]

What about a Valid interface with some reference implementations? It could be worth exploring.

type Validater interface {
     Valid() ([]valid.Error)
}

where valid.Error is also an interface that implements error and stringer

[asdine]

@bketelsen Yes that's the kind of solution i had in mind 👍 Defining an error type and an interface would work better than having an opaque error. Reference implementations would work too if they don't import existing validation libraries (depending on the decision made here #4)

[bketelsen]

@asdine since you and @markbates have the only two validation implementations I know of would you two be interested in proposing a lib for commons?

[asdine]

@bketelsen Sure i'd love to. To sum up IMO we need to define at least:

• a validation interface
• an error type containing informations about the reason of failure

@markbates if you are interested, how would you like to sync ?