我使用基本身份验证，因此URI看起来像http://test:password@site.com/。
如果我想给所有用户，我会创建一个像http://test:password@site.com/users/
这样的URI但是，如果我想给特定用户，我应该使用哪个地址？这应该是
http://test:password@site.com/users/test/
或只是
http://test:password@site.com/test/
或者我不知道。
我问这个问题的原因是这种类型的授权意味着URI已经包含用户名。
提前致谢。
答案 0 :(得分：6)
以分层方式创建资源URI的好处是不会发生任何ID冲突。如果您添加标识为http://test:password@site.com/test/的其他资源类型（例如，角色），则替代版本test可能会出现问题。您必须确保您的ID在所有资源类型上都是唯一的，而不仅仅是特定类型。此外：不再清楚，您的资源URI是指向用户还是角色。
虽然它并不是REST真正需要的，但它是让人们更容易思考REST API的命名之一：“在包含”用户“标签的URI中可以找到用户资源似乎很正常REST本身实际上是URI不可知的，所以它确实无关紧要。但如果你想使用有意义的（人类可读的）URI，我会说
GET http://test:password@site.com/users/
将返回所有用户。
POST http://test:password@site.com/users/
将创建一个新用户和一个带有URI的新资源。
PUT http://test:password@site.com/users/test
将更改使用此URI标识的用户资源，并满足您应该能够获取此用户资源的合理期望
GET http://test:password@site.com/users/test
最后要考虑的事情是：授权用户可能希望访问其他用户的用户资源（这种情况目前可能不太可能）：
GET http://another:password@site.com/users/test
答案 1 :(得分：1)
这是一个很好的问题。我已经检查了Fielding's chapter on REST，HTTP spec和Basic auth RFC，似乎无法找到明确的答案，但我最好猜测URI的身份验证部分不被视为一部分资源识别。这意味着你应该假装它不存在并使用：
//site.com/users/test/
作为单个用户的URI。这是我的推理。
浏览器实施 - 我的当前版本的Chrome和Firefox以及Internet Explorer denies direct input outright会自动隐藏URI的auth部分（test：password @）。
如果user：password @ parts使资源URI唯一，则每个用户的每个资源都是唯一的。这对我来说似乎有点疯狂。
您永远不会想要在外部参考中包含用户名和密码，如下所示：
<a href="https://admin:swordfish@site.com/users/">Log in as admin!</a>
在我看来，在URL中包含身份验证信息是一种破坏无状态并违反第一个REST接口约束（Identification of resources）的黑客攻击，但是它填满并需要，所以我们将它扫到地毯下并假装它并不是URL的真正组成部分。
答案 2 :(得分：0)
您使用该方法的基本问题是网址
//用户：password@site.com/test
相当于
// site.com/test
当您使用密码作为HTTP身份验证标头时
我认识的大多数开发人员都不想在URL上传递用户/密码，因此他们会选择第二个选项。现在你有一个有趣的问题，因为你有两个相同的URL指向完全相同的资源，这与REST相反，但更重要的是，它与HTTP缓存相反。
当您的用户通过任何代理（并且他们无法控制，因为很多代理可以并将由组织和ISP使用）时，您可能正在向其他用户提供用户的缓存版本。不太好。
用户和密码实际上不是URL的一部分。它们是大多数浏览器接受传递http基本AUTH标头的机制，但它不是URL，因此您需要为唯一资源提供唯一的URI。这是REST方式，在GET请求的情况下，如果你不这样做，你应该担心。
顺便说一句，请告诉我你将为此实施https。在http上传递用户和密码是一个非常糟糕的主意。即使你使用HTTPS，鼓励你的用户传递URI中嵌入的用户/传递意味着用户和密码将在系统的每个日志（apache / nginx，app server ...）上清晰可见。那太难看了。因此，我建议您使用https并阻止您的用户在URL上传递AUTH数据。 AUTH数据应作为POST请求中的正文的一部分或作为标头传递。