我需要一个RPG游戏库存API的RESTful实现的想法

Question

我正在研究一种RPG游戏。我试图找出 一个很好的，干净的和RESTful的方式来定义库存API。

库存由几个slots组成，如head，chest等（如在大多数RPG游戏中）。

现在我需要定义REST API移动从X插槽的所有项目槽中Y.

一些想法，我有：

• 很好，显然库存的生命在/inventory
• 所以第1想法是有像/inventory/movement水平，并有一个CREATE在那，使它CRUD。所以它会是POST /inventory/movement。这将是CRUD和REST，但感觉非常糟糕。
• 另一个是在库存上有一些神奇的属性，只是做更新：PUT /inventory?move_from=A&move_to=B。这仍然不太好。

so ..对于这个干净的CRUD REST解决方案的任何想法？

更新：刚才有另一个：PUT /inventory/:to_slot?from=:from_slot - 还不确定。为什么当涉及2个时，只有一个插槽的动作？呃...呃！

Answer 1

由于在REST中，您应始终对资源或资源集合采取行动，在这种情况下，我会将'MOVE'作为REST资源。这可能起初看起来不正确，因为我们认为'MOVE'是一个动词而不是名词，但是如果界面覆盖高度抽象，这可能是有意义的。在暴露用户控制游戏选项的高级界面中，您可能需要采用'MOVE OPTION'，该突然变成名词！

因此，我要使用POST动词去库存中移动的项目，因为我们会发放到请求创建一个新的“MOVE”行动。考虑下面的不言自明的例子：

- POST /move/inventory/a/b 
- POST /sell/inventory/a 
- POST /use/inventory/b 

在原始CRUD操作的“MOVE”命令通常使用CREATE后跟一个DELETE实现。不过，我认为如果你在这样的游戏资源上使用原始的CRUD操作，你会发现它太低级了。

如果您要从x中获取一个项目并将它放在y中，那么您会在哪里放置验证逻辑来​​检查y是否是有效目标？它应该在模型中（在界面后面）还是在游戏中？如果它应该在模型中，那么我认为你应该考虑我之前描述的高层次方法。另一方面，如果您打算在游戏内（界面前）处理这种逻辑，那么您可以采用原始CRUD方法，如Jan suggested in another answer。

请注意，如果您的RPG将面向网络，则必须在服务器端处理游戏逻辑。在这种情况下，我会试图将REST界面与提示给用户的控件和选项一一对应，然后再次提出上面提出的高级模型。

Answer 2

它应该更新域逻辑中的ipotetic Item的position_id，或类似的东西不是吗？

所以我觉得你shuld投入到现有的项目：

PUT /items/:id?position_id=:position_id 

样本：

PUT /items/1?position_id=2 

你已经知道了，因为它应该已经被定义为您的项目模型ISN的“从位置”是吗？

当然，你可以添加/库存/命名空间，如果你喜欢，使其更具描述性的，所以我建议：

PUT /inventory/items/:id?position_id=:position_id 

附：注意后面的参数？不GET参数:)

Answer 3

维塔利，

不认为在行动方面（移动到），但在资源和状态转移的条件。这里是我将如何做你问什么与REST：

 
GET /game/inventories/5536 

200 Ok 
Content-Type: application/rpg.inventory+xml 

<inventory> 
    <slot href="/game/inventories/5536/slot">X</slot> 
    .... 
</inventory> 





PUT /game/inventories/5536/slot 

Content-Type: text/plain (or what you need) 

"Y" 

GET /game/inventories/5536 

200 Ok 
Content-Type: application/rpg.inventory+xml 

<inventory> 
    <slot href="/game/inventories/5536/slot">Y</slot> 
    .... 
</inventory> 

但也可能有其他方式。

月

Answer 4

因为库存只是在人物模型的哈希，你可以为每一个作为要求修改散列重要插槽定制存取度日。

从插槽中的REST风格的移动到B可以像

PUT /inventory with params: 

{inventory => {:worn_on_head => nil, :worn_on_left_arm => @item}} 

你可能简化与验证的参数和回调，甚至使用存取自己，以确保相同的项目不在多个插槽中。从本质上缩短移动请求的参数是这样的：

PUT /inventory with params: 

{:inventory => {:worn_on_left_arm => @item}} 

一个更安全的赌注是，如果用户试图装备比他们拥有的项目的多个副本只是抛出一个验证错误，无需更换其他的一个在变化的时候。