What does json.NewDecoder(r.Body).Decode(&v) accept in a Go handler that a strict API should reject?

## The default is deliberately forgiving `json.NewDecoder(r.Body).Decode(&v)` streams one JSON value out of the request body and into `v`. Its defaults suit a tolerant reader, which is the right posture for consuming somebody else's API and the wrong one for validating input you are about to act on. Three gaps matter for a request handler. ### 1. Unknown fields are ignored Any key in the JSON object that does not match an exported field (by name or `json` tag) is skipped. A client that sends `{"emial": "[email protected]"}` gets a `200` and a user with an empty email, and a client still sending a field you removed last quarter gets no signal. `dec.DisallowUnknownFields()` — called on the `*json.Decoder` before `Decode` — makes that an error instead. Enable it on inbound request bodies where you own both sides, and think twice on a public API: strictness is a compatibility promise, since any field you later stop understanding becomes a hard failure for existing clients. ### 2. Only the first JSON value is consumed `Decode` reads one value and stops. A body of `{"a":1}{"b":2}` or `{"a":1} garbage` decodes the first object successfully and never looks at the rest. The standard fix is to decode again into a throwaway and insist on end-of-input: ```go if err := dec.Decode(&struct{}{}); err != io.EOF { return errors.New("body must contain a single JSON object") } ``` If that second call returns `nil`, the client sent a second value; if it returns any other error, the trailing bytes are not even valid JSON. Either way it is a 400. ### 3. The read is unbounded A `Decoder` will keep pulling bytes for as long as the client keeps sending them. Wrap the body before decoding: ```go r.Body = http.MaxBytesReader(w, r.Body, 1<<20) ``` `MaxBytesReader` returns an `io.ReadCloser` that fails once more than `n` bytes have been read, and it also tells the server not to keep the connection alive after the abort. Use `errors.As` against `*http.MaxBytesError` in your error handling and answer `http.StatusRequestEntityTooLarge`. ## Turning decode errors into good responses `Decode` returns several distinguishable errors, and mapping them is what separates a usable API from one that says "bad request": - `io.EOF` — the body was empty. Say so; clients hit this when a proxy strips the body or a `Content-Length: 0` sneaks through. - `io.ErrUnexpectedEOF` — the body was cut short mid-value. - `*json.SyntaxError` — malformed JSON; the error carries an `Offset` you can quote back. - `*json.UnmarshalTypeError` — well-formed JSON of the wrong shape, e.g. a string where an `int` was declared. It carries `Field` and `Value`, so you can say precisely which key was wrong. - The unknown-field error from `DisallowUnknownFields` is a plain error whose message names the offending key. Use `errors.As` for the typed ones and `errors.Is(err, io.EOF)` for the sentinel, then compose one response body for the client. ## Decoder versus Unmarshal `json.Unmarshal` takes a `[]byte`, so using it means reading the whole body into memory first with `io.ReadAll` — you own the buffer, and you can log the raw bytes, but you also hold it all at once. `json.NewDecoder(r.Body)` streams and never materialises the whole document as a single slice, which is why it is the default choice in handlers. Neither is safe without a cap on how much the client may send. ## Shape of a reusable helper Most codebases end up with one `decodeJSON(w, r, dst) error` function that does all of this: cap the body, construct the decoder, disallow unknown fields, decode, check for trailing data, and translate the error. Writing it once is what keeps the strictness consistent across every endpoint, and it is a good thing to be able to sketch on a whiteboard. ## Interview-ready summary The three defaults to name are: unknown fields ignored, one value read with the remainder skipped, and no size limit. The three fixes are `DisallowUnknownFields`, a second `Decode` that must return `io.EOF`, and `http.MaxBytesReader`. Then map `io.EOF`, `*json.SyntaxError` and `*json.UnmarshalTypeError` onto clear client-facing messages.