API 是否应该为新创建的资源分配并返回参考号？答案

【问题标题】：Should an API assign and return a reference number for newly created resources?API 是否应该为新创建的资源分配并返回参考号？
【发布时间】：2014-03-02 17:55:43
【问题描述】：

我正在构建一个 RESTful API，用户可以在其中使用 post 请求在我的服务器上创建资源，然后通过 get 请求等引用它们。我难以决定的一件事是客户端应该具有哪些 ID。我知道有很多方法可以完成我想要完成的工作，但我希望采用遵循行业惯例和最佳设计实践的设计。

我的 API 是否应该决定每个新创建资源的 ID（它很可能是数据库分配的资源的主键）？还是应该允许用户为其资源分配自己的参考编号？

如果我确实为每个新资源分配了一个参考号，应该如何将其返回给客户？ API 有一些允许创建批量项目的端点，所以我需要在每个响应中列出所有新创建的资源？

我很矛盾，因为允许用户指定他们自己的 ID 显然是一堆蠕虫 - 我需要验证每个 ID 都没有被占用，这使得数据库查询变得更加奇怪，因为我将加入reference# 和 userID 而不是外键。另一方面，如果我为每个资源分配 ID，它要求客户端必须构建某种类型的响应解析器并强制它们遵循我强加的约定。

【问题讨论】：

标签： api asp.net-web-api conventions restful-architecture

【解决方案1】：

为什么不两者都做？让用户在那里创建引用，然后您创建自己的 uid。如果用户必须登录，那么您可以使用那里的参考和用户 ID 唯一键。如果不需要客户端可以忽略它，我也会返回创建的 uid。

【讨论】：

【解决方案2】：

将上述两种方法都开发到我的应用程序中（对我来说）是不切实际的，所以我大胆尝试并允许用户选择他们自己的 ID。我很快发现，这种复杂的开发非常复杂，以至于我的开发时间会增加数周，并导致数据库查询更加复杂和缓慢。因此，在项目的早期，我返回并完成它，以便我为所有创建的资源分配 ID。

现在的生活很简单。

我查看的其他流行 API（例如 Instagram API）也会为某些创建的资源分配 ID，如果您有数百万用户可以与彼此的资源进行交互，这一点尤其重要。

【讨论】：