阅读后:
https://restfulapi.net/resource-naming/
当一个文档有多个唯一 ID 时,我对集合中引用文档的重新分级有疑问。
在链接 Material 中给出了一个例子:
We can identify a single “customer” resource using the URI “/customers/{customerId}”.
或
http://api.example.com/device-management/managed-devices/{device-id}
http://api.example.com/user-management/users/{id}
http://api.example.com/user-management/users/admin
还有我的例子:
http://myserver/api/courses/{id}
它有一个对应的 js Express 函数:
app.get('/api/courses/:id', (req, res) =>...
我的问题是,如果我的文档(类(class))有两个我想使用的唯一 ID key ,我该如何维护一致的 API。
如 ID1 和 ID2。
我将如何在 express 中编写代码以及如何编写 url?
所以如果我需要这两个 API:
http://myserver/api/courses/{id1}
http://myserver/api/courses/{id2}
如果我提供两个 Express 例程:
app.get('/api/courses/:id1', (req, res) =>...
app.get('/api/courses/:id2', (req, res) =>...
并且 ID1 和 ID2 都是同一类型(例如数字)。 REST API 如何区分这两者?
最佳答案
REST 不关心资源标识符的拼写。惯例,如 https://restfulapi.net/resource-naming/ 所描述的那样,大致类似于关于拼写变量名称的编码约定。
从 REST 客户端的 Angular 来看,/api/courses/X
和 /api/courses/Y
是不同的资源——这些资源可能共享相同的底层表示(因为它们是从相同的底层数据构建的),但这是服务器的实现问题。
URI 拼写仅受 RFC 3986 约束.
/api/courses?id1=12345
/api/courses?id2=67890
这是一个非常合理的选择。一个潜在的好处是 HTML 包含一个标准,用于创建带有查询参数的 URI 模板。一个潜在的缺点是相对引用解析处理查询部分中的非分层数据与路径段中的分层数据不同。
/api/courses/id1/12345
/api/courses/id2/67890
完全合理的选择,与上面的权衡相反。
/api/courses/id1=12345
/api/courses/id2=67890
这实际上与上面的想法相同,只是拼写略有不同。它具有简单易读的优点。但是,实际使用该模式可能具有挑战性,具体取决于您拥有何种路由支持。
作为URI templates ,这些可能看起来像
/api/courses/id1={id}
/api/courses/id2={id}
但是在支持 4 级 URI 模板的地方,您可以使用
/api/courses/{/ids*}
另一种可能性是使用受“矩阵参数”启发的拼写,例如
/api/courses;id1=12345
/api/courses;id2=67890
同样,这为您提供了一组不同的可读性、模板支持、相对分辨率支持等权衡。
另见 Stefan Tilkov -- REST: I Don't Think It Means What You Think It Does .
关于javascript - 具有多个 ID 的 Rest API 资源命名,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/56969324/