我有很多资源，例如产品，预订等。需要路线来按用户获取所有资源。
例如：
{GET} /bookings/user
我认为这是不正确的，因为此路由将返回用户资源。还是我错了？
正确的方法是什么？
答案 0 :(得分：1)
我认为这是不正确的，因为此路由将返回用户资源。还是我错了？
它返回由/bookings/user标识的资源的表示形式。那是什么资源？由原始服务器决定。
rest不在乎您用于标识符的拼写约定。就REST而言，/6414b60b-1ecb-4e28-8887-4bfe120810e7是一个非常令人满意的资源标识符。
如果您想要人类可读的标识符，也可以。 RFC 3986鼓励这种做法：
通常人们必须记住一个URI，当URI由有意义或熟悉的组成部分组成时，人们就更容易记住它。
您还应该记住，RFC 3986区分URI中的分层信号和非分层信号
URI语法是按层次结构组织的，列出的组件按从左到右的重要性降序排列。 -section 1.2.3
路径组件包含通常以分层形式组织的数据，以及非分层查询组件中的数据-section 3.3
查询组件包含非分层数据，以及路径组件中的数据（第3.3节），用于标识URI方案和命名权限（如果有）范围内的资源-{{3} }
简而言之，如果您要描述层次结构中描述的信息，那么使用路径段很有意义
我不退还用户名和用户ID，需要退回所有已授权用户的预订。
听起来您正在描述/my/bookings之类的拼写。
一种可能有助于URI设计的启发式方法是考虑section 3.4的好处；与文件系统一样，您可以使用点段导航到名称空间的根。
`/my/bookings` + `../profile` --> `/my/profile`
有 个原因，您可能不希望支持relative references；因此，您需要仔细考虑该约束及其含义。
答案 1 :(得分：0)
通常，人们会为此使用查询参数：
GET /bookings?userId={userId}
这将返回给定用户ID的所有预订。