Expose *Binder interface for more byte oriented payloads

[yanfali]

I have a use case where I have a buffer of JSON that I would like to use binder to deserialize and validate for me. Would it be helpful to add io.Reader oriented interface binder which could be used for this?

This way I can leverage the same validation code for http wrapped sources of data like multipart/form-data.

e.g. JSONReaderBinder(reader *Reader.io, userStruct binding.FieldMapper) binding.Errors

[mholt]

This is a good idea. Here we step out of bounds of net/http and into the Go-verse at large. It's exciting. I would need to adapt the package's documentation and gear its focus toward a general data-binding package, which I think it could become. (Right now it only handles net/http stuff.)

Let's think a little larger for a moment first. A binder that can take an io.Reader (that's what you meant, right?) could be just as useful as one that takes a http.Request like we have now. There may be yet other interfaces or types which we could get data from, and then what comes out of those buffers/requests/whatever would be form-encoded, JSON, XML, etc, and that binding would happen at a different layer, independent of where the data came from.

Does that make sense? It would require a shift in the design of the package, but I think it could be worth the effort.

I don't have a whole lot of time to experiment right now (hopefully with the holidays coming up I could get around to it), but I'd be interested in knowing if you have any thoughts on this, agree/disagree... etc.

[yanfali]

I agree with your conclusions. While I think io.Reader is a good level of abstraction because anything that can be read from is a souce, e.g. bytes.Buffer, I think the error abstraction should probably have configurable adapters that output different things based on the source input. e.g. JSON for json, XML for xml, etc... I'm still a bit new at go, so I'm afraid I don't yet have much taste for what makes an idiomatic go API.