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

Question

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

我的问题是，如果这是一个好主意，通常让商店&市场使用自己的ID，或者如果它是不好的做法。如果我们的方法有意义，我们是否应该检查我们通过商店&商场收到的ID（即与商店相关的用户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是否存在。

如果某些商店系统其实都是建立REST风格，他们可能要实际存储一个URI，而不是ID的，要能够通过自己和你的系统无缝导航。他们只需要将你的media-type添加到他们的客户，就是这样。

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