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

Question

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

我的问题是，如果让商店​​和商店一般是个好主意。市场使用自己的ID，或者如果这是不好的做法。如果我们的方法有意义，我们是否应该对商店收到的ID进行检查＆amp;市场（即与商店相关的用户ID的唯一性）？

通过POST /users/创建新用户的示例有效内容：

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

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

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

Answer 1

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

Answer 2

好吧，一种很酷的（RESTful）方法是接收URI而不是自定义ID。遗憾的是，这意味着这些合作伙伴系统必须发布自己的资源才能链接到它们。这也可以解决唯一性问题，因为您只需要检查URI是否存在。

如果某些商店系统实际上是RESTful构建的，他们可能希望实际存储URI而不是id，以便能够无缝地通过他们自己和您的系统进行导航。他们只需要将media-type添加到他们的客户端，就是这样。

除此之外，确保您可以存储第三方系统的ID。我知道有几个交易系统可以做到这一点，存储各种第三方ID，后端系统，传输层ID等等。至少不是闻所未闻。