处理消息传递时纠正REST端点设计

Question

我正在努力为某种情况找出正确的REST端点。在我的网站上，用户可以相互发送消息。一个用户可以向多个收件人发送邮件。

我认为/ v1 / users / 123 / messages会返回已发送给用户123的所有邮件

我应该对用户123发送的消息使用什么终点？

我的数据库结构如下......

帐户表

id              INT
username        VARCHAR(64)

消息表

id              INT
account_id      INT            <!-- This is the senders account ID
subject         VARCHAR(128)
message         TEXT

messagerecipients表

id              INT
message_id      INT
account_id      INT            <!-- This is the recipients account ID

消息表定义了消息与其发件人之间的一对一关系

messagerecipients表定义了邮件与其收件人之间的多对多关系

---

此刻我正在阅读a PDF on API design，这似乎表明我应该在查询字符串后面隐藏这种复杂性。

例如......

/v1/emails?filter=author_id(123)
/v1/emails?filter=recipient_id(123)

思想？

Answer 1

我会做这样的事情。

获取用户发送的所有消息：

/v1/users/123/sent

获取用户收到的所有消息：

/v1/users/123/inbox

您的数据库结构与资源方案无关，但它可以影响有效负载结构。如果您想使用JSON，则消息可能如下所示：

{
  sender: 123,
  receivers: [124, 125]
  content: "My message content"
}

Answer 2

我希望

/v1/users/123/messages

返回所有属于此用户的邮件。这意味着收到，发送，删除，标记，起草等。

要指定资源的子集，您可以采用两种方式，就像您和bertvh所述：

<强>查询字符串： 我发现它对于过滤非常有效，例如

/v1/users/123/messages?type=received&folder=important

或作为子资源： 如果您希望在更高级别上拥有大量过滤器选项，请使用此选项，例如

/v1/users/123/messages/received?folder=important

如您所见，这会减少过滤器选项。

与bertvh所述，底层数据库架构与提供响应无关。