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

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

Answer 2

同意VoiceOfUnreason

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

不要那样做

针对您的特定用例

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

/{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“这在您的上下文中是正确的< / p>

/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而不是应该用于创建新记录的其他版本。

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

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

3 个答案: