时间戳

首页 > 解决方案 > REST API 中的元素是否应该返回自己的 ID？

rest - REST API 中的元素是否应该返回自己的 ID？

问题描述

返回元素的 ID 有什么好处？它不是已经是 url 的一部分，因此不是已知的吗？我不是在谈论将 REST API 与 HAL 或类似的东西一起使用。

api/employees/1
{
        "Id" : 1
        "Name" : "Joe Bloggs",
        "Department" : "IT"
}

api/employees/1
{
        "Name" : "Joe Bloggs",
        "Department" : "IT"
}

我想添加有关 API 使用的更多信息是有意义的：

有问题的 API 是封闭网络（不是互联网）中的公共 API。我们提供示例客户端，但我们的客户为我们的 API 编写自己的客户端。元素的 ID 不是敏感信息。数据不是关于雇员（如问题中所述），而是关于资产管理。

我要问的原因是，客户抱怨如果他们使用某种中间件（无论是什么），他们只会收到元素的内容，但无法访问元素的 url（如何？）。

如果你自己写客户端，有没有什么情况下不能根据URL获取ID呢？我们是否应该为无法访问 url 的人添加 ID？

标签： rest

解决方案

客户实际使用该 ID 的目的是什么？提供产品 ID 并没有那么错误 IMO，但是当用户使用电子邮件通过 API 进行身份验证时，用户是否必须知道您在数据库中存储用户实体的 ID？所以要回答实际问题：这取决于。但是，如果客户端使用它来构造下一个要调用的 URI，我强烈建议返回具有有意义的关系名称的链接，因为这有助于将客户端与 API 分离，因为客户端不必先验知识API 本身。

根据资源的不同，使用升序 ID 可能没有好处，因为这可能有利于猜测攻击，并且如果您删除集合中间的项目，也可能导致奇怪的情况。后续物品的ID是否更新？项目之间是否存在间隙？通常，UUID 等是公开此类信息的更安全的方式。

要考虑的另一个方面是，理想 REST 环境中的客户端不应解释 URI 本身，而是使用返回 URI 的关系名称来确定是否调用该 URI。从 URI 中提取 ID 的客户端很可能对 API 有一些先验知识，因此与该 API 紧密耦合，如果 API 将被更改，肯定会中断。

话虽如此，URI 模式的概念应该可以帮助客户端从 URI 中提取 ID 和名称等内容。就我个人而言，我并不热衷于这样的事情，因为它们在 API 设计中推广了一种误导性的 REST 应用方法。

如果你自己写客户端，有没有什么情况下不能根据URL获取ID呢？我们是否应该为无法访问 url 的人添加 ID？

提取 URI 的 ID 需要了解 URI 结构。如果您在以后的某个时间想要更改 URI 结构，无论出于何种原因，围绕该知识构建的所有客户端都会中断。URI 不应包含内容，因为正文实际上是用于的。由于 ID 似乎是某些客户端的内容，因此将其包含在响应正文中。您当然可以自由地将一些信息添加到 URI，尽管您不应该要求客户端解析该 URI 并提取它所需的信息。

推荐阅读