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

推荐答案

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

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

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

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.

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

路径元素应该用于分层数据——想想相对 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 中加入带有下划线的复合键是好的/坏的设计吗?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！