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等等。至少這種交易系統並不是聞所未聞的。