在url中使用下划线连接复合键是好/坏设计吗？

Question

我正在寻找以下用例的RESTful API设计的最佳实践:

Table1     Table2
Id1        Id1
Id2        Id2
Id3        Id3
Name       Name
           Table1Id1(FK to Table1)
           Table1Id1(FK to Table1)
           Table1Id1(FK to Table1)

假设我有如下表1的端点:

/root/table1 (to get list of records)
/root/table2 (to get single record by primary key)

现在我的问题是从第二个以下代表第二个网址中的复合键的最佳方式:

/root/e1/Id1/Id2/Id3

or 

/root/e1?Id1=1&Id2=2&Id3=3

假设我有如下表2的端点:

/root/table1/Table1Id1_Table1Id2_Table1Id1/table2 (to get list of records for table2 by table1).

现在这里是我的问题,在url之上是有效的,并且在复合键的情况下是否合适？

关于此用例的良好模式的任何建议将不胜感激.

Answer 1

关于此用例的良好模式的任何建议将不胜感激.

不要将资源标识符与(当前)数据库模式耦合; 这违反了封装.

我正在寻找以下用例的RESTful API设计的最佳实践

REST真的不在乎.就REST而言,URI是不透明的; 编码到其中的任何信息都由服务器自行决定并供自己使用.

相关问题是RFC 3986和您当地的设计惯例.

路径组件包含通常以分层形式组织的数据,该数据与非分层查询组件(第3.4节)中的数据一起用于标识URI方案和命名权限(如果有)范围内的资源.

路径元素应该用于分层数据 - 考虑相对URI解析的方式.

根据你在这里的描述,我不认为外键具有自然的层次结构; 当然不是一般情况下.因此,使用URI(查询)的非分层部分可能更有意义.

另一种考虑的可能性是矩阵参数 ; 您可以将外键组合到单个路径段中,从而避免在它们之间建立任何层次结构.

Answer 2

同意非理性之声

不要将您的资源标识符与（当前）数据库模式耦合；这违反了封装。

不要那样做

针对您的特定用例

作为一般最佳实践，REST URL 应遵循可预测的分层模式来识别资源。这给客户端和服务器之间带来了很大的透明度。因此，假设您的实体中有父子关系，那么最好将其设计为

/{appname}/{version}/parent/{parentId}/child/{childId}

而不是仅仅拥有

/{appname}/{version}/child/{childId}

在您的用例中，URL 的非分层部分是Id1/Id2/Id3

为表提供唯一标识符的最佳方法。但如果真的做不到，那么你应该去尝试

/root/e1?Id1=1&Id2=2&Id3=3

这给出了一个概念“让我的 e1 具有 Id“1” 、 Id“2”和Id“3”，这在您的上下文中是正确的

/root/e1/Id1/Id2/Id3

这是非标准的，因此应该避免

通过table1获取table2的记录列表

你应该有

/root/table1/table2?Table1Id1&Table1Id2&Table1Id1