Question

我有一个正在设计的中央服务 API。现在，centralserive 将接收来自部署在不同位置的众多次中心服务的请求。

一个示例端点看起来像 /api/v1/centralservice/activity

我在设计时收到的建议之一是在 URI 中包含 sub-central-id [部署 subcentral 服务的位置 ID]。在这种情况下，端点看起来像 - /api/v1/centralservice/{subcentral-id}/activity。我被告知的原因是，如果出现网络错误/问题，通过查看日志很容易确定请求是从哪个位置发出的。我在我参与过的任何项目中都没有见过这样的做法。

根据我的理解，正斜杠应该定义资源的层次关系。在我看来，应该通过在标头或请求正文中包含 {subcentral-id} 来处理相同的情况。

任何人都可以对此有所了解并分享它是否是一个好的/坏的做法？

谢谢

Answer 1

<块引用>

任何人都可以对此有所了解并分享它是否是一个好的/坏的做法？

您应该注意的第一件事：机器不关心您为资源标识符使用什么拼写，只要它们与 RFC 3986 中定义的产生式规则一致即可。

当我们设计 URI 时，我们真正要做的是选择一些人，并试图让他们更轻松。

因此，如果在发生网络错误时查看您的访问日志的操作员是您的首要任务，那么设计 URI 时考虑到他们的需求就很有意义。

<块引用>

根据我的理解，正斜杠应该定义资源的层次关系。

URI 的路径部分的描述，取自 RFC 3986，是

<块引用>

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

路径是标识数据的层次结构；但这并不一定意味着识别层次和资源层次是一一对应的。复杂的资源模型不一定有一个整齐的层次结构。

例如，在 HTTP 中，您可以

DELETE /a HTTP/1.1

这并不意味着 /a/ 或 /a/b 或 /a/b/c 会发生什么......网络上的通用组件不根据资源标识符的拼写猜测资源发生了什么。

您可以选择多种不同方式对 URI 中的 subcentral-id 等标识数据进行编码。见RFC 6570。

Answer 2

在开发集成时，使用 URI 和查询参数通常比设置特定标头或以某种特定格式形成正文更容易。 URI 也很容易共享，因为大部分数据都在一个字符串中。

如果端点的目标只是根据请求提供信息，我会避免要求客户端提供除身份验证之外的任何其他内容的标头或正文。

查询 REST URI 设计

2 个答案: