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

Question

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

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

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

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

Вы можете иметь три различных URIs:

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

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

и параметры фильтрации прохода? например

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

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

/comments?user=user_id&post=post_id 

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

Какая у вас лучшая практика?

Answer 1

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

Answer 2

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

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

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