REST标准是否允许URI中存在连续的资源ID？

首先明确：REST核心规范（包括Roy Fielding的REST论文、HTTP标准）里没有明确禁止/something/something/something/{resourceId1}/{resourceId2}这种连续资源ID的写法，但从REST的资源建模逻辑和语义化设计原则来看，这种设计通常不合理，也很难找到合适的适用场景。

为什么不推荐这种写法？ #

REST的URI本质是用来唯一标识资源的，URI的每个分段应该对应资源的层级关系或关联逻辑：

• 合理的层级示例：/users/{userId}/orders/{orderId}，这里orderId属于userId对应的用户资源，层级关系清晰，客户端能直接理解这个URI指向的是某个用户下的某条订单。
• 而连续两个无层级关联的资源ID，比如/products/{productId}/{categoryId}，语义非常模糊：客户端无法直接判断categoryId是产品的属性、关联资源，还是其他含义，完全不符合REST强调的资源语义清晰性。

如果要表达两个资源的关联关系，比如“某个分类下的某款产品”，正确写法应该是/categories/{categoryId}/products/{productId}（明确层级关系）；如果是通过产品找所属分类，用/products/{productId}/category直接指向关联资源更合适；如果需要同时传递两个ID作为查询条件，用查询参数/resources?resourceId1={id1}&resourceId2={id2}会更清晰。

有没有可能合理的场景？ #

如果是复合主键的资源，理论上可以用/resources/{id1}-{id2}这种形式组合成一个唯一标识，而非拆分两个连续分段——因为复合主键本质是一个资源的唯一ID，拆分后反而破坏了资源标识的整体性。

综上，虽然REST没有明确禁止连续资源ID的URI写法，但从语义化和资源建模的合理性来看，这种设计不推荐，也很难找到符合REST资源定义的适用场景。

内容的提问来源于stack exchange，提问作者osama yaccoub