APIを利用した懸賞アプリケーションを作成しています。階層はかなり単純です。
- クライアント
- ユーザー
- 懸賞
- 提出物
クライアントには、基本的に懸賞の管理者であるユーザーを含めることができます。クライアントは、複数の懸賞を持つこともできます。また、1つの懸賞に複数の応募を含めることができます。さて、複雑ではありません。
私が混乱するのは、URL構造に対する正しいアプローチです。インターネット全体でドキュメントやベストプラクティスのブログを読んだことがありますが、それでも混乱しています。現在のルートは次のとおりです。
クライアント
POST / clients
GET / clients
GET / clients /：client_id
PUT / clients：client_id
ユーザー
POST / users
GET / users
GET / users /：user_id
PUT / users /：user_id
DELETE / users /：user_id
懸賞
POST / sweepstakes
GET / sweepstakes
GET / sweepstakes /：sweepstakes_id
PUT / sweepstakes /：sweepstakes_id
DELETE / sweepstakes /：sweepstakes_id
提出物
POST / subjects
GET / subjects
GET / subjects /：submission_id
PUT / subjects /：submission_id
DELETE / subjects /：submission_id
ご覧のとおり、私はリソースごとに単純な2つのURLをフォローしています。これがベストプラクティスだと思います。次に、任意のGETリクエストのクエリパラメータを介して関連付けにドリルダウンできます（例：/ subject？sweepstakes_id = {sweepstakes_id} 、/ sweepstakes？client_id = {client_id}など）。
もちろん、これは私には理にかなっていますが、同僚と私は、Backboneを使用してプライマリフロントエンドアプリを構築しているため、気が遠くなります。Backboneは、RESTful APIの消費をすぐにサポートすると述べていますが、私の同僚は、Backboneはその階層構造を表すURL構造を好むと言っています。もちろん、それは厄介で、長く、全体的に混乱するURL構造につながると思います。理想的には、私の同僚は次のURL構造を見たいと思っています。
GET / clients
GET / clients / users
GET / clients / sweepstakes
GET / clients / sweepstakes / subject
注：上記のルートには、URL内の追加のリソースIDを介して単一のリソースを補完する追加のルートもあります（例：/ clients / users /：user_id、/ clients / sweepstakes /：sweepstakes_id / subjectsなど）。
これはやや厄介な問題であることは知っていますが、これについてのフィードバックをお待ちしています。私はリソースごとに1つの2つのURLに投票します。関連付けを行う必要がある場合は、GETまたはPOSTパラメーターを使用して関連付けることができます。しかし、私は完全に間違っている可能性があります。