REST - 単一のPOSTでネストされたリソースを作成する

Question

RESTfulな方法で考えると、POSTを使用して1回の呼び出しでリソースとそのサブリソースを作成するのは正しいですか？ 私のアプリケーションでは、私はリソース/notices/{notice}とサブリソース/notices/{notice}/photos/{photo}を持っています。 A {photo}は{notice}なしでは存在しませんが、{notice}は必ずしも写真である必要はありません。通常、通知を作成するにはPOSTを最初に行い、写真を追加するには別のPOSTを実行する必要があります。

これで、写真が直接添付された通知を作成することができます。/notices/{notice}と/notices/{notice}/photos/{photo}を作成して、/ notices/{notice}/photos/{photo}両方のリソース（通知のためのJSON、写真のバイナリ）を記述します。私は、サブリソースのLocationヘッダーだけを返すと思います。

これは、Androidクライアントが2つのPOSTリクエストをサーバーに送信して写真付きの通知をアップロードするのを防ぐためです。 これが正しいですか？それともRESTの原則を侵害していますか？それらを別々に保ち、2つの異なる要求をすることを検討すべきでしょうか？あるいは、写真を通知とは別のものと見なすことは間違っていますか？ /notices/{notice}だけをリソースとして保存し、PUTを使用して写真を追加する必要がありますか？

どのソリューションが最適ですか？

Answer 1

はい、親リソースを作成すると同時にサブリソースを作成することには問題ありません。親URLの下のすべてがあなたがアップロードしているリソースの一部である/それに属しているので、POSTの代わりにPUTを使用しても問題ありません。

EDIT：

は、今私は/notices/{notice}/photos/{photo}

に単一POSTリクエストで/notices/{notice}と/notices/{notice}/photos/{photo}の作成を可能に、直接接続されている写真との通知を作成できるようにしたいです私はこれに同意しない。コレクションリソースのURL、/noticesにPOSTすることをお勧めします。あなたは、通知とその写真を単一の表現（リクエストボディ）として提供します。バックエンドは、通知と構成写真の両方のリソースを作成します。

Answer 2

多くの場合、RESTfulアーキテクチャのスタイルでは、多くの場合、複数の編集/作成は形式的には対処されませんが、

問題は、コレクションの一部で障害を報告する必要がある場合に開始され、障害が原因によって異なる場合に問題が悪化します。

クライアントが所定の取引/会話でどのような方法で進むのかがわかる、適切なHypermediaコントロールを選択することになります。

私の提案では、ネストされたリソースを作成するためのPOSTではなく、ネストされたサイクルまたはPOSTリクエストを使用して、各リソース状態の変更に対処することがより簡単で明確になります。