Совокупные данные в API RESTful - программирование

У вас есть интересный HTTP API-вопрос, на который мне хотелось бы высказать некоторые мнения. Мой API позволяет людям оценивать вещи в масштабе 1-10. У меня есть конечная точка GET /ratings, в которой перечислены рейтинги пользователей. Мы также хотим показать среднюю оценку пользователя в день. Итак, мой вопрос: должно ли сводка быть тем же URL-адресом, что и /ratings?data=summary, или должен быть его собственным URL-адресом, например /ratingsummaries или /ratings/summary?

Как это часто бывает, я не думаю, что есть правильный ответ. Является ли сводка просто еще одним взглядом на рейтинги, и в этом случае это будет ресурс рейтингов и должен быть частью /ratings? Или, это сводка рейтингов собственного ресурса, и в этом случае он заслуживает своего собственного URL-адреса, например /ratingsummaries? /ratings/summary тоже выглядит хорошо, но на самом деле это не под-ресурс рейтингов.

С нетерпением ждем ваших отзывов. Спасибо всем!

Ответы

Ответ 1

Мое мнение - иметь его как
/ratings/, когда когда-либо вы вернетесь к списку рейтингов. Параметры поиска обычно задаются как @QueryParam. Например, ratings?offset=20&records=50&startDate=xx&endDate=yy

/ratings/{id}/ для одного определенного рейтинга, идентифицированного идентификатором.

/ratings/{id}/votes за получение голосов по рейтингу.

Рейтинговое заключение отличается от рейтинга, поэтому он является кандидатом на separte url
/ratingsummary?startDate=x&endDate=y

или ваш путь может начинаться с /ratingsummary; это может быть как
/ratingsummary/ratings?offset=20&records=50&startDate=xx&endDate=yy В этом случае у вас есть сводка по рейтингам, затем вы можете перейти к списку рейтингов, которые способствовали сводке, затем к одному состязательному рейтингу и т.д.

Идеально следовать шаблону, например /entities/{idOfOneEntiity}/{attributeOfEntitiy} и т.д.