使用字符串與整數標識符REST風格的URL

一個人如何決定使用字符串與REST風格的URL整數標識符。例如，我發現Github API在某些情況下使用了字符串，例如使用字符串與整數標識符REST風格的URL

GET https://api.github.com/repos/nareshbhatia/git-explorer 
=> get a repository whose id is "git-explorer"

而在其他整數

GET https://api.github.com/repos/octocat/Hello-World/issues/1347 
=> get an issue whose id is 1347

我明白，這是更自然，以確定其名稱的信息庫和其編號的問題，但是從實現的角度來看一個字符串標識符帶來的幾個問題。存儲庫表的主鍵是否應該是名稱？但是一個字符串通常是主鍵的不好選擇。好吧，那麼整型代理鍵的名稱是一個唯一的列。但是，這意味着每當我有一個倉庫（整數）的參考，我需要構建一個URL它，我不得不做了一個連接以存儲庫表 - 只是爲了獲得它的名字。

要澄清一下，假設我創建了JSON的一個問題，我需要包括一個鏈接到庫，我需要一個連接到存儲庫表中創建像/repos/nareshbhatia/git-explorer，而不是一個簡單的鏈接的鏈接只有一個整數像/repos/nareshbhatia/10

來源

2014-02-07 Naresh

參考我不知道我與字符串是一個PK一個不錯的選擇的說法。當然，如果你使用的是自然鍵，你會使用字符串的機率是很好的。許多人更喜歡整數，因爲它們更加緊湊，它們可以提高指數的性能，但性能不應該成爲您唯一的考慮因素，並且自然鍵具有優勢。足夠的數據庫。

當你開始談論的URI，實在是沒有明顯的性能優勢，以較短的網址，所以整數沒有表現過的字符串邊緣。與URI中的整數相比，字符串也具有SEO優勢。這些注意事項可能會導致您使用整數主鍵設計數據庫，但在平穩的端點中使用字符串作爲URI。

來源

2014-02-07 04:36:30 Aheho

我自己傾向於去字符串作爲PK，但在網上的意見似乎是50-50。我還在想，如果這樣的大鍵作爲外鍵出現在關聯表中，那就不對了。這就是爲什麼認爲代理鍵作爲PK的原因。順便說一句，人們真的認爲RESTful API的SEO優勢？我認爲這隻適用於可瀏覽頁面。（當然，我同意即使在REStful API的情況下也是有意義的/可讀的URI更爲可取。） – Naresh

使用字符串與整數標識符REST風格的URL

回答

相關問題