3 ms·
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, to
by addcn 6y ago
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 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.