我有一个带有两个操作的Web API控制器。一个操作返回数据库中所有实体的列表。第二个操作采用查询字符串参数并过滤实体。
搜索操作被连接到使用查询字符串参数。它有效，但是我们遇到了一个不起作用的DOC工具的问题，因为操作签名是相同的(DOC工具没有考虑查询字符串(。
将搜索参数从查询字符串移动到路由中的属性是错误的吗？这是可以接受的方法吗？我不会考虑问题的原因吗？
目前，这是我使用的URL：
domain.com/api/entities?q=xyz
我正在考虑采用基于路线的方法：
domain.com/api/entities/xyz
如果要实现搜索功能或其他类型的功能，其中您需要具有多个可选参数，则最好使用查询字符串参数。您可以提供所有这些，其中一些，或者没有任何一个，然后将它们放置在任何顺序中，并且只能工作。
// Anything Goes
/controller/action?a=123&b=456&c=789
/controller/action?c=789&a=123&b=456
/controller/action?b=456&c=789
/controller/action?c=789
/controller/action
另一方面，如果使用URL路径和路由，则只有在其右侧没有其他参数时才可以是可选的。
// OK
/controller/action/123/456/789
/controller/action/123/456
/controller/action/123
// Not OK
/controller/action/123/456/789
/controller/action/456/789
/controller/action/789
可以自定义路由以任何顺序传递可选值，但是当查询字符串自然适合这种情况时，似乎还有很长的路要走。
要考虑的另一个因素是，放入URL中是否具有需要编码的不安全字符。编码URL的 PATH 的形式很差，有时不可行，但是可以将哪些类型的编码字符的规则放入查询字符串中更加轻松。由于URL不允许空间，因此对多个单词文本搜索字段进行编码是更适合的，请与查询字符串中的空间进行编码(按原样保存(，而不是试图找到解决方案以用A-将查询时必须将其更改为服务器端的空间。
search = "foo bar"
// Spaces OK
/controller/action?search=foo%20bar (works fine and server is able to interpret)
// Spaces Not OK
/controller/action/foo bar/ (not possible)
/controller/action/foo%20bar/ (may work, but a questionable design choice)
/controller/action/foo-bar/ (may work, but requires conversion on the server)
最后，值得考虑的另一个选择是使用帖子而不是get，因为这意味着这些值根本不需要在URL中。