在URL中用下划线连接复合键是好/坏设计吗? [英] Is it good/bad design to join composite key with underscore in url?

问题描述

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

I'm looking for the best practices on RESTful API design for the following use case:

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

假设我对于表1具有如下所示的端点:

Suppose i have endpoints like below for Table1:

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

现在我的问题是，从下面两个最好的方法来表示第二个URL中的复合键:

Now here my question is which would be the best way from below two to represent composite key in second url :

/root/e1/Id1/Id2/Id3

or 

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

假设我对表2具有以下端点:

Suppose i have endpoints like below for Table2:

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

现在这是我上面的问题，在复合键的情况下，在URL上方是否有效?

Now here is my question that is above url valid and appropriate in case of composite key?

对于此用例遵循的良好模式的任何建议，将不胜感激.

Any advice on a good pattern to follow for this use case would be greatly appreciated.

推荐答案

对于此用例遵循的良好模式的任何建议，将不胜感激.

Any advice on a good pattern to follow for this use case would be greatly appreciated.

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

Don't couple your resource identifiers to your (current) database schema; that violates encapsulation.

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

I'm looking for the best practices on RESTful API design for the following use case

REST真的不在乎.就REST而言，URI是不透明的.编码后的任何信息均由服务器自行决定，并由其自己使用.

REST really doesn't care. As far as REST is concerned, the URI is opaque; any information encoded into it is done at the server's discretion and for its own use.

相关的关注点是RFC 3986和您的本地设计约定.

The relevant concerns are RFC 3986, and your local design conventions.

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

The path component contains data, usually organized in hierarchical form, that, along with data in the non-hierarchical query component (Section 3.4), serves to identify a resource within the scope of the URI's scheme and naming authority (if any).

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

Path elements are supposed to be for hierarchical data -- think about the way that relative URIs resolve.

根据您在此处的描述，我不会认为外键具有自然的层次结构；在一般情况下肯定不是.因此，使用URI(查询)的非分层部分可能更有意义.

Based on your description here, I wouldn't think that the foreign keys have a natural hierarchy to them; certainly not in the general case. So using the non hierarchical part of the URI (the query) might make more sense.

要考虑的另一种可能性是矩阵参数；您可以将外键组合到单个路径段中，从而避免暗示它们之间的层次结构.

Another possibility to consider would be matrix parameters; you can combine the foreign keys into a single path segment, thereby avoiding any suggestion of hierarchy among them.

这篇关于在URL中用下划线连接复合键是好/坏设计吗?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！