处理消息传递时正确的 REST 端点设计答案

【问题标题】：Correct REST endpoint design when dealing with messaging处理消息传递时正确的 REST 端点设计
【发布时间】：2014-01-29 16:30:12
【问题描述】：

我正在努力为特定情况制定正确的 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

消息接收者表

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)

想法？

【问题讨论】：

【解决方案1】：

我期待

/v1/users/123/messages

返回所有属于该用户的消息。这意味着接收、发送、删除、标记、起草等。

要指定资源的子集，您可以像您和 bertvh 所说的那样采用两种方法：

查询字符串： 我发现它非常适合过滤，例如

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

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

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

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

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

【讨论】：

【解决方案2】：

我会做这样的事情。

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

/v1/users/123/sent

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

/v1/users/123/inbox

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

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

【讨论】：