liuxiran commented on issue #2924: URL: https://github.com/apache/apisix/issues/2924#issuecomment-739331098
> We should discuss the API design first I'd like to move on from this point. Should API parameters be designed to be **highly consistent with code logic**, or to **maximize user convenience**? I perfer the latter one, because people who use an API can ignore how it's implemented behind it. So when we encapsulate API, I think it is necessary for us to do some data conversion for the better use of the interface by users. Just take `remote_addr` and `remote_addrs` as an example. When user what to config remote_addr - config one remote_addr - config multiple remote_addrs - do not config remote_addr what we're doing now is that we have provided three transmission parameters to the users - when you want to config one remote_addr, you should config `remote_addr` - when you want to config multiple remote_addrs, you should config `remote_addrs` - when you do not want to config remote_addr (one or multiple), you should omit this config item. would it be better that we only give one `remote_addrs` instead of all above? and that will turn to - when you want to config one remote_addr, you can use `remote_addrs: [addr1]` - when you want to config multiple remote_addrs, you can use `remote_addrs: [addr1, addr2, ....]` - when you do not want to config remote_addr, you can just config `remote_addrs: []` or omit it I think they all ok. **Leaving the simple to the user, we need to use code to translate user requirements into better application requirements** ---------------------------------------------------------------- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: [email protected]
