Как спроектировать URI для ресурса, который занимает разные позиции в иерархии?

Question

Каков наилучший способ представления ресурса списка, когда список может "принадлежать" разным ресурсам?

Возьмите типичный пример блога.

Скажем, у вас есть сообщения, комментариии пользователи.Сообщение имеет много комментариев, а пользователь является автором многих комментариев.

Вы можете получить список комментариев в контексте данного пользователя (например, историю комментариев этого пользователя), для данного сообщения (например, все комментарии к этому сообщению) или, может быть, просто все комментарии., период (хотя это не очень вероятно).

У вас может быть три разных URI:

/user/user_id/comments
/post/post_id/comments
/comments

Это нормально?Насколько я понимаю, URI должны быть идемпотентными.Является ли более «RESTful» иметь один URL: / comments

и передавать параметры фильтрации?например,

/comments?user=user_id
/comments?post=post_id

Полагаю, этот второй метод означает, что вы также можете фильтровать сообщения пользователя и с

/comments?user=user_id&post=post_id

Но мне нравится, как в первом примере раскрывается иерархический контекст.

Какая лучшая практика здесь?

Answer 1

Насколько я понимаю, URI должны быть идемпотентными.

URI не являются операциями и поэтому не могут быть описаны как идемпотенты. Идемпотентность просто означает, что если вы выполните одну и ту же операцию дважды, конечное состояние системы будет таким же, как если бы вы сделали операцию один раз. С другой стороны, HTTP-запросы на URI могут быть идемпотентными, но не все они должны быть. Например, HTTP PUT и DELETE должны всегда быть идемпотентными, но HTTP POST может быть или не быть. HTTP GET вообще не должен существенно изменять состояние системы.

Что касается дружественного дизайна URI (касательного к REST), я рекомендую использовать параметры запроса для вещей, которые похожи на запросы; обычно подвыбор некоторого большего набора ресурсов, например, нумерация страниц и / или поиски. В этом случае /user/{user_id}/comments совершенно нормально. Однако я бы посоветовал не выставлять ключи базы данных в URI; это детали реализации, которые вы должны скрывать, чтобы гарантировать, что URI не изменятся позже, когда вы перерастете свою текущую реализацию. Для таких вещей, как значение user_id, лучше использовать другое уникальное значение, например имя пользователя.

Answer 2

Ваш первый пример кажется мне лучшим из двух. Не забывайте, еще более важный момент: ваш сервис должен быть ориентирован на связанные данные. Поэтому, если бы я перешел на /user/123, я бы увидел ссылку [href, a] на /user/123/comments, которая сообщает мне о другой части службы, работающей по этому URI.