REST API设计咨询：帖子点赞与取消点赞的URL规范方案

针对你提到的帖子点赞场景，核心是要把「用户对帖子的点赞关系」作为独立资源来设计，而不是用一个接口承载两种相反操作。以下是更符合REST惯例的设计思路：

核心设计原则 #

REST的核心是资源定位+语义化HTTP方法，点赞行为本质是「创建/删除用户与帖子之间的点赞关联资源」，而不是单纯修改一个数字。

具体接口设计 #

假设系统通过请求头/会话验证当前用户身份，无需在URL或请求体中显式传递用户ID：

1. 查询当前用户是否已点赞该帖子 #

用来让前端判断按钮状态（显示「点赞」还是「取消点赞」）：

GET /posts/{post_id}/likes/me

• 返回200 OK：返回简洁状态，比如{ "liked": true }
• 返回404 Not Found：表示用户未点赞该帖子

2. 点赞操作（创建点赞资源） #

POST /posts/{post_id}/likes

• 请求体：无需额外参数（后端通过身份验证获取当前用户）
• 返回201 Created：响应体包含更新后的帖子点赞数，比如{ "likes_count": 123 }
• 幂等处理：如果用户已点赞，返回409 Conflict（或静默忽略，保持点赞数不变）

3. 取消点赞操作（删除点赞资源） #

DELETE /posts/{post_id}/likes/me

• 返回204 No Content：删除成功，响应体可附带更新后的点赞数
• 幂等处理：如果用户未点赞，返回404 Not Found（或静默忽略）

为什么原方案不符合REST惯例 #

你提到的POST /post/{post_id}/likes加countup字段的问题在于：

• 一个接口承载了「创建」和「删除」两种完全相反的语义，违反了HTTP方法的单一职责原则
• 没有将「点赞关系」作为独立资源暴露，而是把它当成了帖子的一个可修改属性，忽略了REST中资源的独立性

额外优化建议 #

• 在帖子详情接口（GET /posts/{post_id}）中返回likes_count字段，避免前端单独请求点赞数
• 后端要保证点赞操作的原子性，防止并发场景下点赞数统计错误
• 若支持匿名点赞，可用设备ID替代用户ID，调整URL为/posts/{post_id}/likes/{device_id}

内容的提问来源于stack exchange，提问作者JungHwanPark