複雑なリソースをコレクションに追加するベストプラクティス？

Question

ゲーム内のプレイヤーがサーバーにコマンドを送信できるようにする、RESTfulなサービスを想像してください。このコマンドを表すオブジェクトがPlayerCommandと呼ばれ、次のようになり可能性があります：プレーヤー、ゲーム、およびコマンドは、サービスに/リソースオブジェクトされている

PlayerCommand: 
Player player; 
Game game; 
Command command; 
String param1; 
...etc. 

。プレイヤーがこれらを追加できるようにPlayerCommandリソースを公開すると、PlayerCommandリソース（POST/playerCommand）の整形式表現を投稿するために、PlayerCommandエンドポイントを公開する方が良いでしょうか？あるいは、PlayerCommandオブジェクトの複雑さのいくつかを、パスに依存するリソースのIDを入れるだけで、光沢を持たせることをお勧めします。 POST/player/{id}/game/{id}/playerコマンド？後者のように、クライアントの方が簡単で、オブジェクトの表現をより細かく（基本的にはコマンドと文字列パラメータのみ）渡し、サーバ側でIDに基づいて依存オブジェクトを作成させることができます。

基本的に、ネストされた/複雑なリソースに対してCRUD操作を公開する場合、ここではベストプラクティスは何ですか？

Answer 1

リソースの設計要件を絞り込む良い方法の1つは、URIへのGETが、クライアントがクライアントにそのURIにPUTするのと全く同じ表現を送信し、逆もまた同様であることを想像することです。

PlayerCommand表現をPOSTすると、新しいPlayerCommandリソースを作成することを前提としています。 PlayerCommandリソースのGETからそのようなものを返すと、何を返すのですか？レスポンスに埋め込まれたPlayer、Game、およびCommandオブジェクトを完成させますか？そうでない方が良いです。代わりに、それらのリソースを指すURIを返します。

同様に、POSTed表現は、Player、Game、またはCommandリソースの完全な表現を埋め込むべきではありません。代わりに、URIの形式でそれらの識別子を含める必要があります。サーバーは、新しいオブジェクトを作成することなく参照を保存できます。 JSONベースの例：

{"self": "/playerCommand/9803495", 
"player": "/players/84", 
"game": "/games/22980", 
"command": {"base": "/commands/fight", 
      "params": ["kick", "Darrel"] 
      } 
}