通常，为用户设置两条 GET 路由（一条用于 ID，一条用于用户名）是否多余？
In general, would it be redundant to have two GET routes for users (one for ID and one for username)?
我正在为我休息的用户构建一个 CRUD API，目前我的 GET 路由如下所示：
get("/api/users/:id")
但这只是我想到的：如果用户试图通过他们的用户名搜索其他用户怎么办？
所以我考虑实现另一条路线，像这样：
get("api/users/username/:id")
但这对我来说看起来有点多余。更重要的是，如果我的应用程序也应该允许搜索真实姓名的话。那么我需要 3 条路线吗？
那么在这个很棒的社区中，有没有经验丰富的 Web 开发人员可以告诉我他们将如何处理必须通过用户名 搜索用户？
Obs：如果您需要更多详细信息，请发表评论，我会及时更新我的问题
how they would handle having to search for a user via their username?
您如何在网站上支持此内容？
你可能会有一个表格；该表单将有一个输入控件，允许用户提供用户名。当用户提交表单时，浏览器会将表单输入控件复制到一个 application/x-www-form-urlencoded 文档（如 HTTP 标准所述），然后将该文档替换为表单操作的 query_part，并提交查询。
所以最终的请求可能看起来像
GET /api/users?username=GuiMendel HTTP/x.y
当然，您可以根据需要使用不同的输入控件组合来创建任意多种不同的表单。其中一些表单可能会共享操作，但不一定。
so I could just have my controller for GET "/api/users" redirect to an action based on the inputs?
REST 不关心“控制器”——那是一个实现细节；重点是客户端不需要知道服务器如何生成资源的表示，我们只需要知道如何请求它（通过“统一接口”）。
您的 路由框架 可能非常关心，但这同样只是隐藏在外观背后的另一个实现细节。
for example, there were no inputs, it would return all users (index), but with the input you suggested, it would filter out only users whose usernames matched the input? Did I get it right?
是的，没关系。
从 REST 客户端的角度来看
/api/users
/api/users?username=GuiMendel
这些标识不同的资源；这两种资源之间根本不需要有任何有意义的关系。机器不关心（人类 确实 关心，所以我们通常以这样一种方式设计我们的标识符，至少一些人可以轻松地度过它——例如，我们可能会优化我们的标识符，以便在操作员读取访问日志时让事情变得简单。
我正在为我休息的用户构建一个 CRUD API，目前我的 GET 路由如下所示：
get("/api/users/:id")
但这只是我想到的：如果用户试图通过他们的用户名搜索其他用户怎么办？
所以我考虑实现另一条路线，像这样：
get("api/users/username/:id")
但这对我来说看起来有点多余。更重要的是，如果我的应用程序也应该允许搜索真实姓名的话。那么我需要 3 条路线吗？
那么在这个很棒的社区中，有没有经验丰富的 Web 开发人员可以告诉我他们将如何处理必须通过用户名 搜索用户？
Obs：如果您需要更多详细信息，请发表评论，我会及时更新我的问题
how they would handle having to search for a user via their username?
您如何在网站上支持此内容？
你可能会有一个表格；该表单将有一个输入控件，允许用户提供用户名。当用户提交表单时，浏览器会将表单输入控件复制到一个 application/x-www-form-urlencoded 文档（如 HTTP 标准所述），然后将该文档替换为表单操作的 query_part，并提交查询。
所以最终的请求可能看起来像
GET /api/users?username=GuiMendel HTTP/x.y
当然，您可以根据需要使用不同的输入控件组合来创建任意多种不同的表单。其中一些表单可能会共享操作，但不一定。
so I could just have my controller for GET "/api/users" redirect to an action based on the inputs?
REST 不关心“控制器”——那是一个实现细节；重点是客户端不需要知道服务器如何生成资源的表示，我们只需要知道如何请求它（通过“统一接口”）。
您的 路由框架 可能非常关心，但这同样只是隐藏在外观背后的另一个实现细节。
for example, there were no inputs, it would return all users (index), but with the input you suggested, it would filter out only users whose usernames matched the input? Did I get it right?
是的，没关系。
从 REST 客户端的角度来看
/api/users
/api/users?username=GuiMendel
这些标识不同的资源；这两种资源之间根本不需要有任何有意义的关系。机器不关心（人类 确实 关心，所以我们通常以这样一种方式设计我们的标识符，至少一些人可以轻松地度过它——例如，我们可能会优化我们的标识符，以便在操作员读取访问日志时让事情变得简单。