REST API资源命名规范 - User或Users(复数形式)

3

简版

对于一些人,包括我在内,构建REST API中最令人痛苦和头痛的部分之一是确定每个资源的名称和相应的端点。

虽然这当然是个人偏好问题;但社区也推荐一些特定的事项。例如,大多数人,包括我自己,会将他们的资源名称变成复数形式:

GET /notifications
POST /posts

然而,有些情况下,复数形式似乎并不正确。考虑以下示例,其中user实际上代表已登录的用户,而不是整个users资源:

仅与经过身份验证的用户相关的端点

// Phone Verification
POST /user/phone/request
POST /user/phone/resend
POST /user/phone/verify

// User creation based on authenticated and verified phone
POST /user

// Update authenticated user's profile
PUT /user

// Delete the authenticated user
DELETE /user

// Add/remove the authenticated user's profile image
POST /user/image
DELETE /user/image

// Update the authenticated user's device token
PUT /device/token

访问整个用户资源的端点

GET /user
GET /user/{id|self}

在上面的例子中,对我来说,似乎单数的user资源名称更适合,因为在大多数端点上,user指的是经过身份验证的user,而不是整个users数据库。但另一方面,让GET /user返回所有用户似乎很明显是错误的...
因此,我现在在userusers之间犹豫不决 - 我认为两者都有强有力的论据,但非常欢迎其他人对此发表意见...
简短版 - 简单地说,请考虑以下两个端点:
// Get all users
GET /users

// Update the authenticated user's device token
PUT /user/device

以上两种方式在我看来都是正确的。但是问题在于,我不可能同时拥有userusers,在我看来只能选其一。
困境在于:当资源指整个用户数据库时,为什么要使用user?当资源只涉及已认证用户时,为什么要使用users
我无法理解这个问题... 有人对此有什么想法吗?或者,更好的是,有没有替代我的端点结构的解决方案?
更新
经过深思熟虑,我想出了一种替代方案,但我仍然不确定,因为我不太喜欢使用auth资源名称。
考虑以下内容:
// auth = authenticated user
// users = users collection

POST /auth/request
POST /auth/resend
POST /auth/verify

POST /auth
PUT /auth
DELETE /auth

POST /auth/image
DELETE /auth/image

PUT /auth/device/token

GET /users
GET /users/{id}
2个回答

1
显然,人们对此有不同的看法,下面的答案包含了我的个人观点。关键是这都很主观,取决于一个人对某种(类型)资源的看法。
为什么在资源指整个用户数据库时要使用“user”?
在我看来,你永远不应该为包含多个资源的端点使用单数。
然而,有些人认为,出于简单和统一性的考虑,我们应该坚持使用单数来表示所有资源。
当资源只涉及经过身份验证的用户时,为什么要使用“users”?
你会发现有很多不同的意见,但共识和最广泛采用的是通常坚持使用复数,除了只能包含单个项目的资源(例如,只包含一个头像的用户配置文件)之外。
另外,由于根据上述逻辑,使用单数形式表示“用户”资源是没有意义的,我们不想混合单数和复数名称。
// Update the authenticated user's device token
PUT /user/device

你可以将“更新经过身份验证的用户设备令牌”解释为以下内容:
users资源集合中的user实体添加设备令牌。

1
我非常同意,对于集合来说,使用复数是惯例,也是我多年来一直实践的。我一直在思考这个问题,认为我的问题与已认证用户相关的资源有关。这个端点让我感到不舒服 PUT /users/device,因为你应该在资源上声明你正在编辑设备的用户,例如 PUT /users/self/device。现在我在考虑做类似这样的事情 /auth/device,其中 auth 代表已认证的用户(单数)。你对此有什么想法? - Ben Carey
1
@BenCarey 我同意 PUT /users/device 不太合适。PUT /users/id/device/auth/device 都更好一些。个人而言,我更喜欢第一个选项,因为我觉得为授权用户单独设置资源名称是不必要的。 - Laurens Deprost
1
@LaurensDeprost - 欢迎来到我的困境 - 我不想为经过身份验证的用户创建单独的资源; auth,因为这似乎有些过度。但是,使用 PUT /users/{id|self}/device 就不太对,因为您无法更新另一个用户的设备。换句话说,端点将始终是 /users/self/device。我想这并不是世界末日,但作为一个完美主义者,这真的很让我恼火,因为它看起来就不对...啊啊啊。你认为呢? - Ben Carey
@EricStein 感谢您的反馈。这是我养成的一种习惯,我意识到我需要注意它,特别是在较长的答案中。 - Laurens Deprost
2
@BenCarey 我理解你的困境,但我仍然会将其实现为 /users/id/device。这似乎是最符合RESTful的方法。 - Laurens Deprost
显示剩余2条评论

0
如果您的API支持查看其他用户设备数据,则API可以如下所示:/users/$user_id/devices 而当您始终需要获取当前登录用户的设备信息时,API可以简单地为/devices(因为当前用户是暗示的)。
即在您只能访问1个父资源的情况下(比如在这种情况下当前用户总是单数),您可以在API URL中跳过该资源。

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文,
原文链接