将HTTP凭据作为资源标识符的一部分进行处理是一种好习惯吗?

时间:2012-11-24 10:33:16

标签: http rest http-authentication

我正在设计一项需要HTTP基本或摘要式身份验证的服务。我试图权衡使用HTTP凭证作为资源标识符的一部分的利弊。假设每个经过身份验证的用户都有联系人列表。联系人应该是否可用:

https://myservice.com/contacts

或者更确切地说:

https://myservice.com/users/112358/contacts

如果是这项服务,则需要隔离用户。永远不需要一个用户访问联系人或与另一个用户相关联的任何其他信息。出于这个原因,第一种方法似乎更清晰,因为它只公开URL中的必要信息。另一方面,对于不同的HTTP凭据,https://myserevice.com/contacts将是一个不同的资源,我不确定它是一个好的设计。

2 个答案:

答案 0 :(得分:1)

我会选择https://myservice.com/users/112358/contacts

如果仅仅因为可能在某些时候可能被其他用户查看的“用户”之下的资源。例如,用户X能够看到用户112358的文档。

URI的一致性是一个优势。即使使用HATEOAS,URI的一致性并不是外部关注的问题,它将有助于增长和维护API的实现。

答案 1 :(得分:1)

出于同样的原因,您在问题的最后引用,/contacts代表不同的资源,具体取决于提供的凭据,我建议您使用第二个更长的选项。用户是否应该记住并在浏览器中输入这些URL?如果没有,长度和'漂亮'不应该是一个重要因素。

不要忘记,您始终可以将/contacts的临时重定向返回给该用户自己的联系人。