我应该如何命名检查用户是否有权编辑资源的端点？

Question

先说背景：我有一个应用程序，登录用户（员工）X 可以看到所有其他用户（员工）的列表。如果登录用户 X 是管理员（他们的指定），那么他们还可以编辑他们管理的用户的某些属性。例如，正在编辑的用户的位置、职位和部门。需要注意的是，X只能编辑him/her下属的员工，也就是说有些用户X是不允许编辑的。当 X 单击用户进行编辑时，他们会导航到 http:myapp.com/dashboard/editUser/<ID_OF_THE_USER_BEING_EDITED>

这样的页面

显然，X 可以变得聪明并手动编辑 URL 并输入他们不允许编辑的用户 ID，因此在加载编辑表单之前我需要检查 X 是否具有授权编辑用户 Y。如果 X 被授权这样做，那么该页面将显示一个表单（在适当的字段中预先填写了用户的当前属性）以编辑用户。否则，我会显示 'Access Denied' 类消息。

现在我创建了一个命名非常糟糕的临时端点 (/api/v1/maybe_edit_user/?jwt=<TOKEN>&userId=<USER_BEING_EDITED>)。这个看起来怪诞的端点做了两件事：

它从令牌中提取当前登录的用户，并检查它是否具有编辑用户所需的访问级别（通过 GET 参数 userId）
如果是，那么它 returns 响应中的当前属性（姓名、电子邮件、位置、职位和其他内容），然后在显示表单时将其预先填充到适当的字段中。

X 提交表单后，PUT 请求将发送到另一个端点 (/api/v1/users/<USER_ID_OF_Y> PUT) 并更新用户 Y。

虽然这行得通，但我觉得它没有吸引力。我正在努力学习编写符合标准的更好、更清晰、更有条理的代码。

REST 的最佳实践建议所有端点都应该是名词。另一方面，我的端点甚至不是一个简单的动词。这至少是一个被上帝遗弃的短语。

所以，这里的问题是：

我应该如何命名我的端点。
我是否应该使用单个端点来检查权限，并获取正在编辑的用户的属性，就像我现在正在做的那样？或者我应该将它们分成 2 个独立的端点？

Answer 1

访问控制列表是一个无关紧要的问题；忽略它。

资源标识符标识资源。 Resources 是文档的概括。

您想要一个与 RFC 3986 的生产规则一致的标识符，选择能够利用 URI 模板 (RFC 6570) 的拼写通常很方便（但不是必需的），否则机器不会不在乎。

这意味着您可以选择一种对人类来说更容易的拼写；你可以在这里选择哪些人优先。

it returns the current attributes (name, email, location, designation, and other stuff) in the response

这就是您对文档 是什么的提示；某种 Bob 的...概要摘要？员工记录？卷宗？显然针对这种特定形式进行了优化。

所以标识符可以像

一样简单

/this-specific-kind-of-form/source-data/Bob

请求可能看起来像

GET /this-specific-kind-of-form/source-data/Bob HTTP/1.1
Authorization: Bearer <token>

实施看起来很像您的草图 - 验证令牌，将声明与所需声明进行比较，然后 return 资源或客户端错误 (4xx) 的某种形式。

The best practices for REST suggest that all endpoints should be nouns.

不要过度解读。

请注意以下所有资源标识符都有效：

您可以单击任何这些链接，您的浏览器将创建正确的 HTTP 请求，服务器将执行预期的操作。

我应该如何命名检查用户是否有权编辑资源的端点？

How should I name an endpoint that checks whether a user has authority to edit a resource?

api-design

rest