Problem
BindJSON() currently uses Go's default JSON decoder behavior.
This means unknown JSON fields are silently ignored.
Example:
{
"name": "John",
"age": 20,
"unexpected": true
}
The extra field is discarded without notifying the developer.
For APIs requiring strict validation, this may hide client-side mistakes.
Proposed Solution
Introduce a separate helper:
err := c.BindJSONStrict(&req)
Internally:
decoder := json.NewDecoder(c.Request.Body)
decoder.DisallowUnknownFields()
This preserves the existing BindJSON() behavior while offering an opt-in strict alternative.
Why This Matters
Many production APIs prefer rejecting unexpected fields because they often indicate:
- Client typos
- Version mismatches
- Invalid requests
Providing both APIs gives developers flexibility without introducing breaking changes.
Tests
Add coverage for:
- Valid JSON
- Unknown fields returning an error
- Validation still working correctly
Backward Compatibility
No breaking changes.
Existing BindJSON() remains unchanged.
Hey @DevanshuTripathi, I'd be happy to work on this implementation, #GSSOC'26.
Problem
BindJSON()currently uses Go's default JSON decoder behavior.This means unknown JSON fields are silently ignored.
Example:
{ "name": "John", "age": 20, "unexpected": true }The extra field is discarded without notifying the developer.
For APIs requiring strict validation, this may hide client-side mistakes.
Proposed Solution
Introduce a separate helper:
Internally:
This preserves the existing
BindJSON()behavior while offering an opt-in strict alternative.Why This Matters
Many production APIs prefer rejecting unexpected fields because they often indicate:
Providing both APIs gives developers flexibility without introducing breaking changes.
Tests
Add coverage for:
Backward Compatibility
No breaking changes.
Existing
BindJSON()remains unchanged.Hey @DevanshuTripathi, I'd be happy to work on this implementation, #GSSOC'26.