javascript - 具有多个 ID 的 Rest API 资源命名

问题描述

看完之后：

当文档具有多个唯一 ID 时，我有一个问题要重新评估集合中的引用文档。

在链接的材料中给出了一个例子：

我们可以使用 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) =>...

我的问题是，如果我的文档（课程）有两个我想使用的唯一 ID 密钥，我如何维护一致的 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 如何区分这两者？

标签： javascriptrestexpress

解决方案

REST 不关心资源标识符的拼写。约定，如https://restfulapi.net/resource-naming/所描述的约定，大致类似于关于拼写变量名称的编码约定。

从 REST 客户端的角度来看，/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 模板，这些可能看起来像

/api/courses/id1={id}
/api/courses/id2={id}

但是在你有 4 级 URI 模板支持的地方，你也许可以使用

 /api/courses/{/ids*}

另一种可能性是使用受“矩阵参数”启发的拼写，例如

/api/courses;id1=12345
/api/courses;id2=67890

同样，这为您在可读性、模板支持、相对分辨率支持等方面提供了不同的权衡。

另请参阅 Stefan Tilkov - REST：我不认为它意味着您认为它的作用。

javascript - 具有多个 ID 的 Rest API 资源命名

问题描述

解决方案

推荐阅读