3 ms·
Is it a good idea to validate API query string parameters?
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'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'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 6y agoHey! 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 6y agoCool, 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.