Правильная конструкция конечной точки REST при работе с сообщениями

Question

Я изо всех сил пытаюсь выработать правильные конечные точки REST для определенной ситуации. На моем сайте пользователи могут отправлять сообщения друг другу. Один пользователь может отправлять сообщения нескольким получателям.

Я думаю, что/v1/пользователей/123/сообщения будут возвращать все сообщения, которые были отправлены пользователем 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/messages 

вернуть все сообщения, которые принадлежат этому пользователю. Это означает, что он получен, отправлен, удален, помечен, составлен и т. Д.

Чтобы задать подмножество ресурса вы можете пойти двумя путями с этим, как вы и bertvh заявил:

QueryString: Я считаю, что вполне допустимо для фильтрации, как, например,

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

Или как subresource: Используйте это, если вы ожидаете, чтобы иметь много вариантов фильтра на более высоком уровне, например,

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

Как вы можете видеть, это уменьшило бы вариант фильтра.

И как указано в bertvh, базовая схема базы данных не имеет отношения к обслуживанию ответов.

Answer 2

Я бы сделал что-то вроде этого.

Чтобы получить все сообщения, отправленные пользователем:

/v1/users/123/sent 

Чтобы получить все сообщения, полученные пользователем:

/v1/users/123/inbox 

Ваша структура базы данных не имеет отношения к схеме ресурсов, но это может повлиять на структура полезной нагрузки. Если вы хотите использовать JSON сообщения могут выглядеть примерно так:

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