ユーザーが個人レコードを作成するフォームがあります。各人は、身長、体重など、いくつかの属性を持つことができます。ただし、興味、お気に入りの映画などの関連データのリストを持つこともできます。
このすべてのデータが収集される単一のフォームがあります。私には、このすべてのデータを1回のリクエストでPOSTする必要があるように思われます。しかし、それはRESTfulですか？私の読書は、興味、お気に入りの映画、その他のリストを別々のPOSTリクエストに追加する必要があることを示唆しています。しかし、それらの1つが失敗する可能性があり、その場合、Personの部分的な挿入があり、彼らの興味やお気に入りの映画が欠落している可能性があるため、それは意味がないと思います。
それは、依存データのアドレス可能性と一意性に完全に依存していると言えます。
ユーザーに関連付けられたデータがユーザーに依存している場合（つまり、「個別の」文字列、たとえば映画の（未検証の）名前を表す文字列などの属性）、ユーザーのPOST作成に含める必要があります。表現; ただし、データがユーザーから独立している場合（データをユーザーから独立してアドレス指定できる場合、たとえば、一連の映画の映画などの参照）、データを独立して追加する必要があります。
この背後にある理由は、元のPOSTにバンドルされている場合の参照の追加は、トランザクション性を意味するということです。つまり、別のユーザーが「お気に入り」の映画の映画参照をクライアントで選択されてからPOSTが実行されるまでの間に削除すると、ユーザーの追加は失敗します（その設計によるはずです）が、「お気に入り」の映画の場合連想ではなく単なる属性であり、失敗するものは何もありません（属性は（おそらく）サードパーティによって無効化することはできません）。
繰り返しになりますが、これはあなたの特定のニーズに非常に当てはまりますが、私は部分的な挿入を許可し、失敗を示す側に落ちます。部分的な挿入を本当に許可したくない場合にこの種のことを処理する適切な方法は、バックエンドでトランザクションを実装することです。これらは、重要な関連リソースがプロセスの途中で削除される状況を真に処理する唯一の方法です。
RESTの実際の制限は、GETした変更可能なリソースの場合、同じ表現を元に戻して状態を変更することもできるということです。またはPOST。他のものの大きな束であるリソースを取得することは合理的（そして非常に一般的）であるため、物事の大きな束を置くことも完全に合理的です。
RESTのリソースについて非常に広く考えてください。データベースの行と1対1でマッピングできますが、必ずしもそうする必要はありません。アドレス可能なリソースは、他のアドレス可能なリソースを埋め込んだり、それらへのリンクを含めることができます。表現と基礎となるプロトコルの操作のセマンティクス（つまり、HTTP GET POST PUTなど）を尊重している限り、RESTは、作業を楽にしたり困難にしたりする可能性のある他の設計上の考慮事項について何も言うことはありません。
本質的にメインリソース（つまり、あなたの場合は人）に関連付けられている限り、1つのリクエストにすべてのデータを追加することに問題はないと思います。興味があれば、お気に入り。映画などはそれ自体がリソースであるため、そのように扱う必要があります。