私は現在、ASP.NET Web API、EF5 Code First アプローチを使用して、REST 風の Web サービス バックエンドを作成しようとしています。おそらく最もよく知られている初心者のエラーを回避するためのアドバイスを探しています。
次のような多対多のシナリオでコントローラー構造をモデル化する最良の方法は何ですか。
タグが関連付けられたブログ投稿があるとします。ブログ投稿には多くのタグを付けることができ、タグは多くのブログ投稿に割り当てることができます。ブログの投稿とタグは、それぞれ顧客に属します。かなり標準的です。しかし、私の最初の懸念は、次の (標準の?) エンドポイント設計でブログ投稿を更新する方法です。
GET - /api/posts/{id} => Load the post by id
DELETE - /api/posts/{id} => Delete the post by id
POST - /api/posts/ => Create a new post from the JSON in the body
PUT - /api/posts/{id} => Update the post from the JSON in the body. Tags as well
1.) タグを単純に配列に POST し、[{"name":"tag1"}, {"name":"tag2"}]
タグが顧客にとって新規か既存のものかをサーバーに認識させ、ブログ投稿を作成するためにタグを割り当てるだけでよいのでしょうか。
2 つのステップ (最初に投稿を作成し、次にタスクを作成して割り当てる) で行うのは、分断された Web の世界では適切ではありません。
2.) 更新プロセスについてもほぼ同じことが言えます。オブジェクト全体を PUT して、サーバーに更新自体を試行させるのは良い習慣でしょうか?
現在、上記のツールチェーンを使用してこの「基本的な」シナリオを実装しています。しかし、解決策はすでにかなり複雑に感じられます。特に、多対多の関連付けを手作業でいじったり設定したりすると、思ったよりも複雑になります。
同時実行処理に関して言えば、クライアントからすべてがダウンし、サーバーがすべてを見つける必要がある場合、切断されたシナリオでこれがすべて簡単に処理できるとは確信していません。
では、API の観点から見たこの (簡単な?) シナリオの「正しい」実装は何ですか? エンティティの作成/更新を分割する方が簡単でしょうか? しかし、サーバーが2つ以上のリクエストが1つの作成/更新に属するように、個別のリクエストを結び付ける方法を自問します。
願わくば、誰かがこの時点まで読んで、私の毛むくじゃらの考えに従ってください。