消息的 REST API 设计

Question

我在网站上有两种类型的用户：简单用户（客户）和专业用户（表演者）。

表演者可以包含在第三种实体类型 - 团队中。

客户可以

• 客户端可以写入客户端。
• 客户端可以写入执行者。
• 客户可以写信给团队。

表演者可以

• 执行者可以写入客户端。
• Performer 可以写信给 Performer。
• 表演者可以写信给团队。

您可以建议哪些 API 路径来处理消息流，具体考虑以下几点：

1) 客户和执行者应该能够互相写消息并向团队发送消息。

2) 客户和表演者应该能够获得他们正在参与的“聊天”列表。

使这个流程成为 RESTful 的最佳实践是什么？

UPD。

表格

我会尽量具体一点 - 我有这些表格：

• client

  • 存储所有客户端的数据（client_id、first_name、last_name 等）

• performer

  • 存储所有表演者的数据（performer_id、first_name、last_name、service_area_title 等）

• team

  • 仅包含团队的头衔和一些元数据，例如performers_count

• teams_performers

  • team_id, performer_id

  • 对于 NxM 关系

至于messages，存在以下表格：

• message
  • message_id, message, owner_id, owner_type, created_at
  • owner_type 是 ENUM，可以是 client 或 performer
• chat
  • chat_id, created_at, updated_at
  • updated_at 与聊天中最后一条消息的 created_at 相同
• chats_participants
  • chat_id, participant_id, participant_type
• chat_messages
  • chat_id, message_id

API

基本api url如下：api.site.com/v1/

客户、表演者和团队可以被视为资源，即我已经有如下方法：

• 创建客户

  POST api.site.com/v1/clients

• 表演者更新

  PATCH api.site.com/v1/performers/:performerId

• 获得表演者参与的团队

  GET api.site.com/v1/performers/:performerId/teams

• 从团队中移除表演者

  DELETE api.site.com/v1/teams/:teamId/performers/:performerId

Answer 1

让我们试着回答你真正的问题

使这个流程成为 RESTful 的最佳实践是什么？

我建议您从阅读开始，Richardson maturity model 将是一个好的开始。

它概述了 4 个levels 来实现一个restful api，这些都是作为起点的好原则，对于高层次的理解。

• 0 级 - 不平静（标准 rpc）
• 第 1 级 - 使用单个资源
• 第 2 级 - 使用 HTTP 动词（获取、删除、发布等）
• 第 3 级 - 最后是超媒体控件

我会去的巢穴是http://restcookbook.com，它填补了更多实现特定问题的空白。

现在有了您所获得的所有知识，您应该能够轻松地设计您的 API。