敏感资源的 REST API URI 设计答案

【问题标题】：REST API URI Design for sensitive resources敏感资源的 REST API URI 设计
【发布时间】：2020-10-19 12:05:25
【问题描述】：

我有一个由 RESTFul API 支持的应用程序。该应用程序具有用户管理部分，管理员用户可以通过该部分管理其他用户。以下是 API 操作端点之一的示例 URI。

这里 user1 是管理员正在编辑的用户的用户名。

安全方面的建议是从 URI 中删除用户名，因为它是敏感信息，并且由于它是 url 的一部分，它将被记录在网络日志中。建议的解决方案是在 POST 请求正文中传递用户名数据。

将数据移动到请求正文是可以的。但是，如果我从 URI 中删除用户名，则 URI 将类似于 "**POST https://example.com/api/users**" 。这显然不像是有效的 REST URI。而且我的 USER 实体没有任何其他可以使用的唯一属性在 URI 中。

在这种情况下，有什么推荐的方法来形成正确的 REST URI 吗？

【问题讨论】：

标签： api rest uri

【解决方案1】：

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

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

【讨论】：

【解决方案2】：

POST /api/users

这显然不像一个有效的 REST URI。

确实如此。

REST 不关心您对资源标识符使用什么拼写，只要拼写与 RFC 3986 中的生产规则一致。

也就是说，文档的标识符需要包含敏感信息并没有什么特别的原因。

有几种可能的解决方案 - 如果客户端和服务器都知道敏感数据，那么您可以使用散列值而不是原始值作为标识符的一部分。

这并不理想：我们有机械的方式来传达接受参数的 URI，但没有我知道的用于传达某些值应该首先被散列的标准。

如果按需代码是一个选项，您可能能够设法指示通用客户端在发送数据之前对其进行哈希处理。

否则，我认为您只能在带外传达散列 - 想象一个指示人类输入敏感信息的散列值的 Web 表单。

REST 针对其优化的用例进行了优化，这意味着其他一些用例比我们可能想要的更笨拙。权衡取舍万岁。

【讨论】：