使用支持多种超媒体类型和身份验证的REST框架。我不确定如何处理的一件事是资源中的敏感值。例如，如果我要在API中包含用户管理，我需要一种方法向客户端公开密码的字段，但不显示实际的密码哈希。信用卡也一样。如果我不这样做，它将违反超媒体约束，因为对字段的了解会变得带外，并使我的HATEOAS破坏。
这是我遇到的实际用例：
该项目是一个人们的目录，展示他们，以便其他人可以雇用他们。有两种类型的用户：具有配置文件的用户和没有配置文件的用户。对于用户而言，资源周围的设计为/users/{userid}，而/users/{userid}/profile或/profile/{profileid}则包含返回给用户的链接，以便客户端可以获得用户姓名等内容。 ，用户可以在/users/{userid}/creditcards/{creditcardid}存储信用卡。
要显示用户的个人资料，您还需要用户资源才能访问姓名和诸如此类的内容。我们不想要的是在用户资源或信用卡链接上公开用户的密码。我想我可以隐藏信用卡链接，没有任何问题，但我不确定密码字段。我应该只为授权用户公开它，而不是在其他用户模型上公开它？我应该提到，除非经过身份验证和授权，否则只允许用户GET。
强调这一点的一个奇怪的边缘情况将是您可以部分访问更改的对象。假设您是一名低级管理员，可以访问更改用户的姓名和地址，但不能更改密码。由于您没有访问权限，因此无法公开密码字段。如何对我没有所有字段的资源PUT进行操作？我应该在这些情况下使用PATCH吗？
TL; DR：如何正确隐藏/公开REST API中的字段并遵循超媒体约束？
答案 0 :(得分：1)
我刚才在这里回答了类似的问题：Authorization dependent REST API（并将您的问题作为相关问题解答）。
答案 1 :(得分：0)
首先，在有敏感信息时始终使用SSL。如果您使用SSL，您的请求将被加密。甚至URL也是通过网络加密的。但是，还有很多其他地方可以用明文记录相同的URL（例如代理服务器，负载平衡器，DNS服务器），因此不要在URL中放置任何敏感信息。
那么这对您的REST API意味着什么？首先，不要在ID中使用敏感信息。您的信用卡号可能是唯一的，但不要将其用作卡的标识符。
此外，在获取资源时永远不会返回密码。您应该在服务器上过滤此类信息。您可以在请求正文中接受它，但不应该在响应正文中将其发回。
对于你的另一个奇怪的边缘情况，PATCH还不是一个标准。直到它成为一个，我看到很多人使用POST来进行部分资源更新。 POST不一定是幂等的，所以它实际上很有意义。因此，POST是部分更新，PUT是在给定ID下创建或替换的。听起来不错？
如果你还没有看过Les Hazlewood关于HATEOAS的演讲，我建议你这样做。它提供了对最佳实践的非常好的概述。