在 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)

现在我的问题是，在第二个 url 中表示复合键的最佳方式是以下两个：

/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（查询）的非分层部分可能更有意义。

要考虑的另一种可能性是matrix parameters；您可以将外键组合成一个路径段，从而避免它们之间的任何层次结构。

Answer 2

同意 VoiceOfUnreason

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

别这样

针对您的特定用例

作为一般的最佳实践，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

Answer 3

迄今为止我见过的最好的 REST API 设计指南是 Google 的：https://cloud.google.com/apis/design/

关于您问题的主题，它包含以下 3 个部分：

• Resource Oriented Design：谈论一种考虑端点的一般方法。
• Resource Names：描述了命名资源的好方法。
• Standard Methods：描述何时使用 GET 与 POST 以及其他 HTTP 方法。

这是一本非常好的读物，我强烈推荐。

根据 Google 指南回答您的问题，我会说：使用 /root/e1/Id1/Id2/Id3 而不是应该用于创建新记录的其他版本。

但您可能不应该像其他答案所建议的那样公开您的数据库架构。这就是我在上面提到“面向资源的设计”部分的原因。您可能希望在表格之上进行某种抽象。除非您的操作是对数据库架构本身的显式操作。