20

興味深い HTTP API に関する質問があります。意見をお聞かせください。私の API を使用すると、1 から 10 のスケールで物事を評価できます。GET /ratingsユーザーの評価を一覧表示するエンドポイントがあります。また、ユーザーの 1 日あたりの平均評価を表示する方法も必要です。だから私の質問 - 要約は のように同じ URL にする/ratings?data=summary必要がありますか、または のような独自の URL にする必要があります/ratingsummaries/ratings/summary?

よくあることですが、正解はないと思います。概要は評価の単なる別のビューですか? その場合、それは評価リソースであり、の一部である必要があり/ratingsますか? または、評価の概要は独自のリソースであり、その場合は のような独自の URL に値し/ratingsummariesますか? /ratings/summaryも良さそうに見えますが、実際には評価のサブリソースではありません。

フィードバックをお待ちしております。皆さんありがとう!

4

1 に答える 1

4

私の意見では
/ratings/、評価のリストが戻ってきたときのようにすることです。通常、検索パラメータは として与えられます@QueryParam。例えばratings?offset=20&records=50&startDate=xx&endDate=yy


/ratings/{id}/ID で識別される 1 つの特定の評価。


/ratings/{id}/votes評価に関する投票を得るために。

評価の概要は評価とは異なるエンティティであるため、別の URL の候補になる
/ratingsummary?startDate=x&endDate=y

か、パスを/ratingsummary;で開始できます。この場合
/ratingsummary/ratings?offset=20&records=50&startDate=xx&endDate=yy 、評価の要約があり、要約に貢献した評価のリストにドリルダウンし、次に特定の評価にドリルダウンできます.

/entities/{idOfOneEntiity}/{attributeOfEntitiy}などのパターンに従うのが理想的です。

于 2012-09-09T18:01:45.990 に答える