既存のアイテムをREST APIのコレクションに追加するための最適なパターンは何ですか？

私は実用的なREST APIを設計していますが、既存のエンティティをコレクションに追加する最善の方法に少し立ち往生しています。私のドメインモデルには、サイトのコレクションを持つプロジェクトが含まれています。これは厳密な多対多の関係であり、関係を明示的にモデル化するエンティティ（ProjectSiteなど）を作成する必要はありません。

私のAPIにより、消費者は既存のサイトをプロジェクトに追加できます。ハングアップしているのは、本当に必要なデータはProjectIdとSiteIdだけだということです。私の最初のアイデアは：

1. POST myapi/projects/{projectId}/sites/{siteId}

しかし、私も考えました

2. POST myapi/projects/{projectId}/sites

JSONコンテンツとして送信されるSiteエンティティを使用します。

オプション1はシンプルで機能しますが、あまり適切ではないため、このパターンに従うことができない他の関係があるため、APIに矛盾が生じます。

オプション2は良い感じですが、2つの懸念につながります。

• 新しいサイトが投稿された場​​合（SiteId = 0）、サイトを作成するか、例外をスローする必要がありますか？
• 関係を作成するためにProjectIdとSiteIdのみが必要なため、他のプロパティのデータが間違っているか、欠落しているサイトが投稿される可能性があります。

3番目のオプションは、関係を作成および削除するためだけに単純なエンドポイントを提供することです。このエンドポイントでは、ProjectIdとSiteIdのみを含むJSONペイロードが必要です。

どう思いますか？

POSTは「追加」動詞であり、「処理」動詞でもあります。PUTは「作成/更新」動詞（既知の識別子用）であり、完全なターゲットURIが既知であるため、ここではほとんど正しい選択のように見えます。projectIdそしてsiteIdあなたは、新しいIDを生成するために、「コレクションにPOST」する必要はありませんので、すでに存在しています。

PUTの問題は、PUTしているリソースの本体を本体にする必要があることです。ただし、ここでの目的は、サイトリソースを更新するのではなく、「プロジェクト/サイト」コレクションリソースに追加することです。

誰かが既存のサイトの完全なJSON表現をPUTした場合はどうなりますか？コレクションを更新し、オブジェクトを更新する必要がありますか？それをサポートすることはできますが、それは意図ではないようです。あなたが言ったように、

本当に必要なデータはProjectIdとSiteIdだけです

むしろ、siteIdコレクションにPOSTを試みて、POSTの「追加」および「プロセス」の性質に依存します。

POST myapi / projects / {projectId} / sites

{'id'： '...'}

Site リソースではなく、サイトコレクションリソースを変更しているので、それが必要なURIです。POSTは「追加/処理」を認識し、そのIDを持つ要素をプロジェクトのサイトコレクションに追加できます。

JSONを具体化し、IDを省略することにより、プロジェクトの新しいサイトを作成するための扉が開かれたままです。「IDなし」==「ゼロから作成」。しかし、コレクションURIがIDを取得し、それ以外の何も取得しない場合、何が起こる必要があるかはかなり明確です。

興味深い質問。:)

このようなPatch方法でメソッドを使用します。やりたいことは、既存のプロジェクトを変更して、サイトを追加することです。

だからこのようなものはうまくいくでしょう

PATCH myapi/projects/{id} 

リクエスト本文にJSON / JSONArrayとしてサイトエンティティを含めます。

そうすれば、必要に応じて同じURLを使用してプロジェクトのさまざまな部分を変更できます。実装のコードは、リソースのこの部分的な変更を処理するのに十分インテリジェントでなければなりません。