リソース設計の良いところは、(ある程度) 理にかなっている限り、それほど重要ではないということです。明らかに、いくつかのニュアンスが整っていますが、ポイントに行きましょう. ビジネス モデルはリソースに 1:1 をマップしません (する必要はありません)。これがおそらく、Twitter API でそのような関係が見つからない理由です。
いくつかの仮定: タイムラインは事前に定義されており、その動作は影響を受けない、または新しいツイートを作成することによる。お気に入りはツイート (への参照) です。お気に入りは影響力があります。
お気に入りのコレクション リソースは次のようになります。
「CRUD」操作は次のようになります。
[POST] /user/bob/favorite{ "tweet_id": "343fe4a" } -- 新しいお気に入りを追加[GET] /user/bob/favorite-- ユーザー Bob のすべてのお気に入り[DELETE] /user/bob/favorite/343fe4a-- ツイート 343fe4a をお気に入りとして削除
通常、1 つのリソースに複数の変数を含めることは避けるのが最善です。これにより、不要な複雑さが生じるからです。ただし、この例では、お気に入りには独自の識別子がありません。代わりに、ツイートの識別子を再利用し、ユーザーと密結合しています。
お気に入りに独自の識別子がある場合は、次のようなリソースを作成します。/favorite/ef213e13fこれは、メタデータを返したり、HTTP GET メソッドのツイートへのエイリアス (リダイレクト) として機能したり、何かを「お気に入りから外す」ためのリソースとして機能したりできます。 (DELETE メソッド)。
ツイートについてではなく、記事やコメントを含むブログについて話している場合、このステートメントはおそらくより理にかなっています。
/blog/article/42-- 記事を表す/blog/article/42/comments-- この記事のすべてのコメントのコレクションを表します/blog/comment/44571-- 単一のコメントを表す
必要に応じて、タイムラインのいくつかの例を次のようなリソースにすることができます。
/user/bob/timeline/home/user/bob/timeline?type=home/timeline/home?user=bob
前述したように、1 つのリソースで複数の変数を使用することは避けるのが最善です。おそらくオプション 3 を選択します。理由は、変数が多すぎるという複雑さに加えて、そのようなリソースは (クライアント側で) キャッシュする価値がなく、CUD アクションが実行されない可能性があるためです。さまざまなエンティティの集約リソースである可能性が最も高いためです。
締めくくりの言葉：
- 最初にリソースを設計してから、一致する URL を考え出す
- リソースを 1 対 1 で (ビジネス) モデルに設計しない
- 最初から状況を考えすぎないでください。何かを実装し、それをいじって、将来起こりうる問題を確認します。満足したら、製品に入れます。
さらに読むための提案: