将复杂资源添加到集合的最佳实践？

想象一下，RESTful服务可以让玩家在游戏中向服务器提交命令。它表示该命令的对象可能被称为PlayerCommand和看起来像：将复杂资源添加到集合的最佳实践？

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

凡播放器，游戏机，和命令也都在服务对象/资源。当我公开PlayerCommand资源以允许玩家添加这些资源时，最好公开一个PlayerCommand端点，从而他们可以发布PlayerCommand资源的良好表示形式，即POST/playerCommand？或者，让它们通过将相关资源的id放在路径中，例如让它们掩饰PlayerCommand对象的一些复杂性，会更好。 POST/player/{id}/game/{id}/playerCommand？看起来后者对于客户来说更容易，让它们传递对象的稀疏表示（基本上只是命令和字符串参数），然后让服务器端根据ID构建依赖对象。

基本上，当在嵌套/复杂资源上暴露CRUD操作时，这里的最佳实践是什么？

来源

2011-06-20 Richard Handworker

答案沿线是否将实体与最终用户之间的关系暴露出来？这种情况下的对象称为PlayerCommand，因为它将玩家映射到游戏中的命令。但是这看起来像是数据模型的实现细节;客户端可能不必担心这些映射，而是将自己限制在根实体（Player，Game，Command）并让服务器端处理关系？这将为我提到的第二个解决方案争论。 –

缩小任何资源设计需求的一个好方法是想象一下，GET到它的URI将向客户端发送完全相同的表示形式，客户端将放入该URI，反之亦然。

当你发布一个PlayerCommand表示时，我假设你想要创建一个新的PlayerCommand资源。当你从PlayerCommand资源上的GET返回这样的东西时，你会返回什么？嵌入响应中的完整播放器，游戏和命令对象？最好不要;相反，返回指向这些资源的URI。

同样，POSTed表示不应该嵌入Player，Game或Command资源的完整表示;相反，它应该以URI的形式包含它们的标识符。然后服务器可以存储引用而不必为它们创建新的对象。一个基于JSON的示例：

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

来源

2011-06-22 05:42:23 fumanchu

啊，我明白了。我没有考虑过客户端发送URI。 –

将复杂资源添加到集合的最佳实践？

回答

相关问题