用于非基于 Web 的应用程序的 REST 类型 API，这是个好主意吗？

Question

我们正在开发 C++ 和 Java 的中间件 SDK，供游戏开发人员、动画软件开发人员、Avatar 开发人员等用作库/DLL 以增强他们的产品。

在使用对特定函数的特定调用创建典型 API 之后，我正在考虑通过使用 REST 类型 API（GET、PUT、POST、DELETE）或 CRUD 类型（CREATE、READ、UPDATE、DELETE）接口来简化 API。

这与客户端-服务器类型 REST API 的工作方式类似，其中只有 4 种可能的 API 调用，但这些可以采用灵活的参数。

这似乎具有使 API 稳定的好处，因为不会添加新调用并且不会删除旧调用。因此，此 API 的使用者不必担心必须重新编译和更改他们的代码以适应我们中间件的任何更新。

开销是中间件控制器中有一个额外的重定向层来路由 API 调用，开发人员需要知道每个 REST 调用可用的参数（当然提供）。

到目前为止，我还没有看到这个系统在 Web 类型的客户端服务器应用程序之外使用，所以我的问题是：这是一个可行的想法吗？

我考虑的是它的效率，以及游戏开发者是否会发现它易于使用。

Answer 1

是的，这是一个可行的想法。但我不确定这些好处是否能证明成本是合理的。 REST 最适用于以请求和响应为导向的网络应用场景。虽然统一接口具有一定的学习曲线优势，但这些优势几乎可以体现在任何设计良好且提供合理抽象过程的 API 中。

您还对游戏开发人员是否会发现 RESTful API 易于使用表示担忧。我会半信半疑。我已经实现了许多 RESTful Web 服务，并帮助许多开发人员加快了构建和使用它们的速度，掌握 REST 所需的概念飞跃对于多年来一直沉浸在过程 API 中的人来说可能是巨大的。我认为游戏开发者尤其会与程序 API 紧密相连，以至于尝试采用不同的范式，无论它有什么好处，都可能非常困难。

Answer 2

请记住，REST 并非特定于 HTTP，并且不仅仅依赖于 4 个 HTTP 动词。您拥有和可以使用的动词取决于您使用的协议。