在 RESTful URI 中包含电子邮件答案

【问题标题】：Including email in restful URIs在 RESTful URI 中包含电子邮件
【发布时间】：2012-12-24 14:16:14
【问题描述】：

在我的应用程序中，我的 URI 包含用于识别用户私有资源的用户 ID。而用户 ID 是电子邮件，例如：

/users/user2@example.com/private-resource

将电子邮件放在 URI 中是一种很好的做法，包括 . 和 @ 等字符？还是我应该使用其他类型的用户 ID？比如哈希？

【问题讨论】：

【解决方案1】：

如果电子邮件可以用作fixed identifier，那就没问题了。

问题是大多数时候应用程序将允许用户更改电子邮件；在这种情况下，自己控制 ID 空间会更加防弹，例如通过使用surrogate key。（因为电子邮件（如果用户可以更改它们）不是身份，而仅仅是资源的一个属性。

另一个反对电子邮件的论点是——正如@Rob 指出的——一个潜在的安全问题。

【讨论】：

好吧，你是对的，电子邮件可能不是不可变的，而且它是敏感数据，代理键是最好的选择。如果我实现代理键，如果用户不知道他的代理键，我如何让用户访问他的个人资料（即/users/{userid} 上的 GET 请求）？ RESTful 无状态语义要求避免使用像 /users/myprofile..这样的 URI。
@user1781028，你可以让用户输入/users/{email}，然后返回一个HTTP 302/users/{id}作为位置；如果用户不存在，则返回 404。

【解决方案2】：

虽然在 uri 中有 '-' 绝对没问题。不鼓励使用“@”、“#”

但是，只要电子邮件 id 是一个 id，例如http://example.org/user/mail/{电子邮件}/1234 猜对了。

【讨论】：

抱歉，我从w3.org/Addressing/URL/uri-spec.html 得知@ 与$ | - | _ | @ | . | & | + | - 一起被视为安全字符。

【解决方案3】：

这没有问题...只要确保您对适当的字符进行 URL 编码即可。

（不过，电子邮件是一种敏感信息，如果 URL 被传递，您可能希望传递哈希或代理键来保护用户的电子邮件地址。）

【讨论】：