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

Question

我正在开发一种RPG游戏.我正在尝试找出一种很好,干净且RESTful的方式来定义库存API.

库存由几slots样head,chest等等(就像大多数RPG游戏).

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

我的想法很少:

• 好吧,显然库存仍然存在 /inventory
• 因此,第一个想法就是让人喜欢/inventory/movement并CREATE制作它CRUD.所以它会POST /inventory/movement.这将是CRUD和REST,但感觉非常糟糕.
• 另一个是在库存上有一些神奇的属性,只是对它进行更新:PUT /inventory?move_from=A&move_to=B.这仍然感觉不太好.

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

更新:刚才有另一个:PUT /inventory/:to_slot?from=:from_slot- 还不确定.当涉及2时,为什么只对一个插槽采取行动？嗯......唉!

Answer 1

由于在 REST 中，您应该始终对资源或资源集合进行操作，因此在这种情况下，我会将“ MOVE ”操作视为 REST 资源。乍一看这可能看起来不正确，因为我们认为“ MOVE ”是动词而不是名词，但如果接口涵盖了高级别的抽象，这可能是有意义的。在向用户公开可用于控制游戏的选项的高级界面中，您可能想要对“ MOVE OPTION ”进行操作，它突然变成了一个名词！

\n\n

因此，我将使用 POST 动词来移动库存中的项目，因为我们将发出创建新的“ MOVE ”操作的请求。考虑以下不言自明的示例：

\n\n

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

\n\n

原始 CRUD 操作中的“ MOVE ”命令通常通过 CREATE 和 DELETE 来实现。但是，我认为如果您要对这样的游戏资源使用原始 CRUD 操作，您会发现它的级别太低。

\n\n

如果您要从 x 获取一个项目并将其放入 y，您会将检查 y 是否为有效目的地的验证逻辑放在哪里？它应该在模型中（界面后面）还是在游戏中？如果它应该在模型中，那么我认为您应该考虑我之前描述的高级方法。另一方面，如果您打算在游戏中（在界面前面）处理此逻辑，那么您可以采用原始 CRUD 方法，正如Jan 在另一个答案中建议的那样。

\n\n

请注意，如果您的角色扮演游戏要面向网络，则必须在服务器端处理游戏逻辑。在这种情况下，我将寻求将 REST 接口与提示给用户 \xe2\x80\x93 的控件和选项一对一映射，并且我再次建议上面提出的高级模型。

\n