使用路由与查询字符串参数是错误的吗? [英] Is it wrong to use routes versus query string parameters?

问题描述

我有一个带有两个操作的 Web API 控制器.一个操作返回数据库中所有实体的列表.第二个操作采用查询字符串参数并过滤实体.

I have a Web API controller with two actions. One action returns a list of all entities from the database. The second action takes a query string parameter and filters the entities.

搜索操作连接到使用查询字符串参数.它可以工作，但我们遇到了文档工具无法工作的问题，因为操作签名是相同的(文档工具不考虑查询字符串).

The search action is wired up to use the query string parameter. It works but we encountered an issue with a doc tool not working since the action signatures are the same (the doc tool does not take into account the query string).

将搜索参数从查询字符串移动到路由中的属性是错误的吗?这是一种可以接受的方法吗?会不会导致我没有想到的问题?

Is it wrong to move the search parameter from the query string to an attribute in the route? Is this an acceptable approach? Will is cause problems I'm not thinking about?

目前，这是我使用的网址:

Currently, this is a URL I use:

domain.com/api/entities?q=xyz

我正在考虑转向基于路由的方法:

I'm considering moving to a route-based approach:

domain.com/api/entities/xyz

推荐答案

如果您正在实现搜索功能，或其他类型的功能，您需要多个可选参数，最好使用查询字符串参数.您可以提供全部、部分或不提供，并按任意顺序排列，这样就行了.

If you are implementing a search feature, or other type of feature where you need to have multiple optional parameters, it is better to use query string parameters. You can supply all of them, some of them, or none of them and put them in any order, and it will just work.

// 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 路径和路由，则一个参数只有在其右侧没有另一个参数时才可以是可选的.

On the other hand, if you use URL paths and routing, a parameter can only be optional if there is not another parameter to the right of it.

// 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

可以通过自定义路由来以任何顺序传递可选值，但这似乎还有很长的路要走当查询字符串很适合这种情况时，就去吧.

It is possible by customizing routing to be able to pass optional values in any order, but it seems like a long way to go when query strings are a natural fit for this scenario.

另一个需要考虑的因素是放入 URL 的值是否具有 其中需要编码的不安全字符.对 URL 的路径进行编码是一种糟糕的形式，有时不可行，但是关于可以放入查询字符串的编码字符类型的规则更加宽松.由于 URL 不允许使用空格，因此更适合使用查询字符串中的空格对多词文本搜索字段进行编码(保留原样)，而不是尝试找到一种解决方案来换出空格- 放入查询字符串，然后在运行查询时必须将其改回服务器端的空格.

Another factor to consider is whether the values being put into the URL have unsafe characters in them that need to be encoded. It is poor form and sometimes not feasible to encode the path of the URL, but the rules of what types of encoded characters that can be put into a query string are more relaxed. Since URLs don't allow spaces, it is a better fit for a multiple word text search field to be encoded with the space in the query string (preserving it as is) rather than trying to find a solution to swapping out the space with a - to put into the query string and then having to change it back to a space on the server side when running the query.

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)

最后，另一个值得考虑的选择是使用 POST 而不是 GET，因为这意味着这些值根本不需要出现在 URL 中.

Finally, another choice worth considering is using POST instead of GET, as that would mean these values wouldn't need to be in the URL at all.

这篇关于使用路由与查询字符串参数是错误的吗?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！