我正在开发一个应用程序，普通用户应在该应用程序上对自己的数据具有读写权限，而管理员对所有人的数据具有读取权限。
在我的设计中，管理员可以：
GET /users
GET /users/:id
但是对于普通用户，我想到了两种路由方案。第一个只是第一个的延续：
GET /users/:id
GET /users/:id/edit
PATCH /users/:id
第二个资源是另一个资源，该资源取决于已登录的用户：
GET /profile
GET /profile/edit
PATCH /profile
我在第二种方法上看到的优势在于，设计本身不允许用户更改URL并尝试编辑其他人的记录。
但是，维基百科说：
统一资源标识符（URI）是明确标识特定资源的字符串。
而且据我所知，/profile不适合该描述，因为不同的用户将看到并更新不同的记录。
所以，问题是：
/profile是否设置正确的URI？感谢<3
PS：在这种情况下，URN可能比URI更准确。
据我所知，这不是一个好主意，但是如果走那条路，您可能会摆脱它。
首先，很重要的一点是，识别资源的URI的强大功能之一就是您可以轻松共享该URI（例如，将其粘贴到消息中），并且收件人可以使用它。在通常情况下，无论谁使用标识符，标识符的含义都是相同的，也就是说，客户端和服务器都同意URI所指。
[当您开始尝试根据与查询关联的标识提供个性化的资源表示时，您会失去一些语义上的约定。
第二个问题是target-uri是HTTP缓存故事中的重要元素；还有其他条件在起作用，但主要条件是请求中的目标uri是否与存储的响应的目标uri相匹配。
因此很容易成像：爱丽丝要求某种资源的表示，但是她没有看到自己的资源视图，而是看到鲍勃对资源视图的表示，因为鲍勃在某些公共缓存中可用。
哪个会很糟糕。
虽然实际上并没有发生；我们如何告诉鲍勃的爱丽丝？标准答案是我们在Authorization标头字段中具有该信息。但是，HTTP缓存具有特殊的规则，当请求包含授权标头时，这些规则将对共享缓存生效。
因此这些规则将保护您，除非您尽力弄乱（例如，使用public cache control directive）。
总结：可以吗？是的，一点没错。你应该...？我最终决定不这样做。如果我需要使用代名词URI，那么我将使用它来重定向到适当的资源，而不是依赖于通过授权标头进行内容协商。
与大多数问题一样，答案是“取决于”-在这种情况下，取决于谁是这些URI的主要使用者。如果是用户，则/profile是完全可以接受的，因为还需要用户体验。与会话cookie提供的状态一起，它唯一地代表一个用户。再举一个例子-在电子商务网站/basket或/baskets/:id上哪个更好？显然是前者，因为它允许用户直接导航到URI，而不必记住他们的购物篮ID（可能随着时间的变化而变化）。
相反，如果主要用户是API客户端，则格式/users/:id可能更合适，因为这允许采用更一致的编码方法。尽管即使在这里，仍可能值得为/users/current之类的URI提供一些负担。即使您在API中遵循HATEOAS的原则，您仍然需要从某些单例资源（如根路径）中获取相关的URI来进行调用。
通常要记住的是，这些只是指导性原则，而不是一成不变的规则-对于您的应用程序和上下文而言，什么有意义对其他人的应用程序而言可能并不相同。
我认为问题是：“基于程序的上下文，我的路线是否应称为/profile？”我不应该这样。我认为您应该有一个基本用户，并运行类似权限级别的东西。像is_admin或is_moderator。