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

Question

我们正在开发一个中间件SDK，使用C++和Java两种语言编写，作为库/DLL供游戏开发者、动画软件开发者、Avatar开发者等使用，以增强他们的产品。我们已经创建了一个典型的API，使用特定的调用来实现特定的功能，但现在考虑通过使用REST类型API（GET、PUT、POST、DELETE）或CRUD类型（CREATE、READ、UPDATE、DELETE）接口来简化API。

这将类似于客户端-服务器类型的REST API，其中只有4个可能的API调用，但这些调用可以使用灵活的参数。这似乎有助于使API稳定，因为不会添加新的调用，也不会删除旧的调用。因此，API的使用者无需担心必须重新编译和更改其代码以适应我们的中间件更新。

然而，这样做的代价是在中间件控制器中多了一层重定向路由API调用，开发人员需要知道每个REST调用可用的参数（当然是提供的）。我迄今为止还没有看到这种系统在Web类型的客户端服务器应用程序之外使用，所以我的问题是：这是一个可行的想法吗？我考虑它的效率以及例如游戏开发者是否会发现它易于使用。

- Ian Wilson

Answer 1

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

您还表达了对游戏开发人员是否会发现RESTful API易于使用的担忧。我持怀疑态度。我已经实现了许多RESTful Web服务，并帮助许多开发人员快速掌握它们的构建和使用，而理解REST所需的概念跨度对于那些已经沉浸在过程化API中多年的人来说可能是巨大的。我认为，尝试采用不同的范例（无论其益处如何）可能会极其困难，特别是对于游戏开发人员。

- Avi Flax

Answer 2

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

- aehlke