
Is it a good idea to validate API query string parameters? - zcyk
My company is revisiting our API design and trying to decide whether to validate query string parameters. From my investigation it looks like most major APIs allow extra parameters and just ignore them, but I haven&#x27;t been able to figure out why. It seems to me that validating parameters is the way to go since it prevents strange results when parameter names are misspelled. So I&#x27;m interested in any thoughts on why those APIs might behave the way they do, and any opinions about whether restricting parameters might be a good idea.
======
addcn
Hey! few quick thoughts on this.

No API is static, so over time expect to add or deprecate query parameters
even if can't conceive of needing changes today, tomorrow, or next quarter.
Change leads API providers to relax validation rules on inputs as part of
avoiding regressions. It's very hard to get all the users of a public API to
update their usages, so hard rules like not allowing extra parameters are
likely to break folks over time.

If it's an internal API with a dozen or fewer consumers you control, then go
ahead, add some rules :)

I'm working on a new feature for the Optic project [1] that can tell you if a
proposed API change will break any of your consumers -- sort of like an
automated consumer-driven-contract-test.

[1] [https://github.com/opticdev/optic](https://github.com/opticdev/optic)

~~~
zcyk
Cool, thanks for the input. This is indeed a public API with many users. Seems
to me that you can account for backwards compatibility while still restricting
query string parameters, by just keeping old parameters in the whitelist, or
by using API versioning. But I suppose I can see this being a factor that
leads teams toward unrestricted parameters.

