我正在创建一个RESTful Web服务，我有一个这样的URL：
GET /pets
对于普通用户，这应该只返回属于该用户的宠物。但对于管理员，它应该返回系统中的所有宠物。这样做有误吗？或者我应该这样做
GET /pets?ownedBy=Smith
并且只有在用户是史密斯或管理员的情况下才允许访问宠物？
答案 0 :(得分：5)
我不认为REST规范具体提到它的任何内容。但IMPO，我认为根据请求用户返回结果是完全正确的。 URL应尽可能保持清洁。如果用户信息已作为标题的一部分出现，则不需要以冗余方式提供URL。
答案 1 :(得分：3)
虽然Juned Ahsan的答案完全正确恕我直言，但我可能会将您的网址模式修改为
GET /史密斯/宠物：为史密斯先生寄回宠物
授权现在可以在URL中一层完成，URL始终代表相同的资源。我倾向于选择这种解决方案，因为在它上面添加缓存层会更容易。将用户（从HTTP标头）添加到缓存密钥效率不高，也不容易为某些缓存解决方案配置。
答案 2 :(得分：1)
我只会在URL中提供它，如果你也有将其他人的名字放在那里的情况。例如，如果人们能够看到他们的朋友宠物，或者管理员是否能够看到所选择的人的宠物。
因此，在您拥有该参数的用户的情况下，暴露它并始终使用它是有意义的。
如果情况并非如此，那么API中的简单性通常是件好事。
要回答问题中的“可以”以及“应该” - 这完全有可能。究竟如何实现它将取决于您正在使用的框架，但他们都支持这一点。
答案 3 :(得分：1)
这两个网址不同。
第一个给出一份宠物清单。
第二个也给出了宠物列表，但在这种情况下，列表由属性“所有者”过滤。这没有任何问题。我会稍微改变第二个URL：
GET /pets?owner=Smith
这个URL的关键是，结果的类型是相同的（宠物实体列表），意思也是一样的。只有一个过滤器应用于列表。这就是在REST中进行查询的地方。
在某些情况下，Path参数会更好。如果你有实体“人”，它有一个类型为宠物类型的属性，我会创建一个像
这样的路径/<user>/pets
如果宠物列表是根元素，我会使用查询。
答案 4 :(得分：1)
我认为这取决于后端服务的实施。目前，我在WCF RESTful服务上以类似的方式工作（尽管对于Android）。如果您有一些可以在数据库中添加的角色，那么在您的服务中应用它并不困难，并且您的网址与此无关。
编辑：如果您确实希望在网址中包含某些内容，则可以随时添加。但我认为根本没必要。用户看得越少越好。
答案 5 :(得分：0)
如前所述，Christian Kuetbach使用REST，您将传递由/分隔的参数
如果您有任何其他特定于用户的功能，或者/<userid>/pets可能是其他方式，则为/pets/<userid>。我建议使用UUID作为用户ID - 这样可以确保用户详细信息的安全性