I'm a junior developer working on my first job.

We encountered an error in our application because a teammate misused a endpoint we made, making a typo in an optional parameter in a POST body leading the backend to continue as if the optional parameter was not set.

I'm wondering what is usually the best approach to prevent these kinds of user errors, is it a bad practice to have endpoints checks that they only receive the request body data they expect with no extra fields?

CodePudding user response：

Is it a good practice on a REST api to check for unexpected parameters in the body?

Maybe. More degrees of freedom is good for compatibility, but that benefit needs to be measured against the increased complexity.

You can think of the body of the HTTP request as a message, with a schema - that schema might be implicit or explicit, it might be a standardized message or something bespoke.

Problem: how confident are we that schema won't need to change? How expensive is it to coordinate a change between the server and the remote client(s)?

One way to keep the costs of future change in check is to design your message processing models such that new clients can communicate with old servers, and new servers can communicate with old clients.

The simplest processing model that enables compatible changes is to ignore content that is not understood. -- David Orchard, 2003

You can still report on unrecognized fields, which would give server operators a mechanism for detecting clients with typos in their schema implementations. A possibly friendlier operational experience, at the cost of more code. Trade offs.

One form of complexity that may arise when ignoring content: it becomes (somewhat?) more difficult to distinguish normal traffic from hostile traffic. See Dan Bergh Johnsson's work on Secure By Design.