REST API URI 敏感資源設計

Question

我有一個由 RESTFul API 支持的應用程序。 該應用程序具有用戶管理部分，管理員用戶可以通過該部分管理其他用戶。 下面是 API 操作端點之一的示例 URI。

更新用戶： POST https://example.com/api/users/user1

這里user1是管理員正在編輯的用戶的用戶名。

安全方面的建議是從 URI 中刪除用戶名，因為它是敏感信息，並且因為它是 url 的一部分，它將被記錄在網絡日志中。 建議的解決方案是在 POST 請求正文中傳遞用戶名數據。

將數據移動到請求正文很好。 但是，如果我從 URI 中刪除用戶名，則 URI 將類似於 "**POST https://example.com/api/users**" 。 這顯然不像一個有效的 REST URI。 而且我的 USER 實體沒有任何其他可以在 URI 中使用的唯一屬性。

在這種情況下，是否有任何推薦的方法來形成正確的 REST URI？

Answer 1

一種方法是使用“id”而不是“username”：

https://example.com/api/users/{id}

其中“id”通常是 UUID https://en.wikipedia.org/wiki/Universally_unique_identifier

Answer 2

POST /api/users

這顯然不像一個有效的 REST URI。

當然可以。

REST 不關心您為資源標識符使用的拼寫，只要拼寫與 RFC 3986 中的生產規則一致。

也就是說，文檔的標識符需要包含敏感信息並沒有什么特別的原因。

有幾種可能的解決方案 - 如果客戶端和服務器都知道敏感數據，那么您可以使用散列值而不是原始值作為標識符的一部分。

這並不理想：我們有機械的方式來傳達接受參數的 URI，但沒有我知道的用於傳達某些值應該首先被散列的標准。

如果按需代碼是一個選項，您可能能夠在發送數據之前設法指示通用客戶端 hash 數據。

否則，我認為您只能在帶外傳達散列 - 想象一個 web 表格，指示人類輸入敏感信息的散列值。

REST 針對其優化的用例進行了優化，這意味着其他一些用例比我們可能想要的更笨拙。 權衡取舍萬歲。