REST API應該選擇ID還是名稱字段？

我設計一個REST API，並試圖決定是返回單一資源的比較正確的做法：REST API應該選擇ID還是名稱字段？

/resource/{id}

或

/resource/{name}

的ID是不變的，所以我認爲選擇它會更好，但名稱會更友好。最佳做法是什麼？我已經看到在「野外」之前都使用過。

基本上REST是建立在唯一ID的頂部，從而：

GET /resources/{id}/

應該被使用。但是，沒有什麼能夠阻止您將name字段設置爲唯一的（現在它的行爲與普通的舊ID一樣）並在此唯一ID之上構建REST。

如果這不是您需要什麼，name不能作出唯一的，那麼另一個選擇是通過name實現過濾：

GET /resources?name=<SOME_NAME>

還應該resources（複數），因爲它表明，有一個集合在引擎蓋下。

2015-07-20 07:20:46 Opal

謝謝，我們與您的建議選擇id並允許按名稱過濾。 –

當然，不客氣:) – Opal

你應該總是喜歡合成鑰匙。如果您將該名稱用作唯一ID，那麼您將對API的未來修訂施加限制 - 您永遠無法使其成爲非唯一的，並且您需要開始返回301s，這可能會影響性能客戶端。 –

/resource/{id}在技術上更爲正確，但如果是我，我會允許這兩者。假設names不能包含一次數字，並且ids只能是數字，您可以很容易地檢測到提供了哪些數字並允許使用。）

2015-07-19 21:57:59

無論是使用名稱而是實用的歸結爲您的商業案例。

會'名'總是是唯一的嗎？或者應用程序是否會處理不止一次的事件？

'漂亮'的網址很重要嗎？在我工作的大多數應用程序中，查詢使用的唯一ID從不向最終用戶公開，因爲它們毫無商業含義。它們實際上是代理主鍵。

2015-07-20 07:28:54 morsor

這是很好的問題..這取決於商業案例例如，如果API通過像搬運工CLI使用，那麼你可能想使用用戶友好的ID，如名稱但只要它成爲URL的一部分，它有一個像ASCII的侷限性（以避免網址編碼或可讀性的損失）只有字符和一些定義的長度，如128個字符等

2017-12-20 15:33:49

回答