REST-API 设计 - 允许自定义 ID

Question

我们正在设计一个 API，市场和在线商店可以使用它来为他们的客户创建付款。为了减少市场和商店在实施我们的 API 时必须做的工作，我们希望让他们能够使用自己的用户 ID 和合同 ID，而不是存储我们创建的 ID。这对他们来说更容易，因为他们不必 change/extend 他们的数据库。在我们的数据库内部，我们仍将使用我们自己的技术 ID。到目前为止，我们没有运行对自定义 ID（即唯一性）进行任何检查。

我的问题是，让商店和市场使用自己的 ID 通常是个好主意，还是不好的做法。如果我们的方法有意义，我们是否应该运行检查商店和市场收到的 ID（即与商店相关的用户 ID 的唯一性）？

通过POST /users/创建新用户的示例负载：

{
   customUserId: "fancyshopuserid12345",
   name: "John",
   surName: "Doe"
}

现在商店可以运行 GET 请求 /users/fancyshopuserid12345 通过我们的 API 检索新用户。

编辑： 我们现在采用这两种方法。如果他想使用自己的 ID，他会像上面的示例那样做，如果他将 false 设置为 customUserId 的值，我们将我们的内部 ID 设置为值。

Answer 1

嗯，一个很酷的 (RESTful) 方法是接收 URI 而不是自定义 ID。不幸的是，这意味着那些合作伙伴系统必须发布自己的资源才能 link 给他们。这也将解决唯一性问题，因为您只需要检查 URI 是否存在。

如果某些商店系统实际上是 RESTfully 构建的，他们可能希望实际存储 URI 而不是 id，以便能够在他们自己的系统和您的系统中无缝导航。他们只需要将您的 media-type 添加到他们的客户中，仅此而已。

除此之外，当然可以存储第三方系统的ID。我知道一些交易系统就是这样做的，存储各种第三方 ID、后端系统、传输层 ID 等。至少不是闻所未闻。

Answer 2

我个人认为这是一个很棒的功能！而且我在这里看不到任何问题。
我还认为您没有验证客户 ID，只需检查它是否没有注入您的持久层就足够了。
此外，您没有违反任何 REST 约定 - 这就是为什么我认为这是个好主意...

REST-API 设计 - 允许自定义 ID

REST-API design - allow custom IDs

architecture

api

rest

api-design

restful-architecture