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

时间:2008-09-15 12:50:20

标签: api rest middleware

我们正在开发一个中间件SDK,用C ++和Java作为库/ DLL,例如,由游戏开发商,动画软件开发商,Avatar开发人员来增强他们的产品。

使用特定函数的特定调用创建了一个典型的API我正在考虑使用REST类型API(GET,PUT,POST,DELETE)或CRUD类型(CREATE,READ,UPDATE,DELETE)接口来简化API。 / p>

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

这似乎有利于使API稳定,因为没有添加新的调用并且没有删除旧的调用。因此,此API的使用者无需担心必须重新编译和更改其代码以适应我们的中间件的任何更新。

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

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

我在思考它的效率以及游戏开发者是否觉得它易于使用。

2 个答案:

答案 0 :(得分:3)

是的,这是一个可行的想法。但我不确定这些好处是否合理。 REST最适用于面向请求和响应的网络应用程序场景。虽然统一界面有明确的学习曲线优势,但几乎所有设计良好的API都可以提供这些优势,这些API提供了相当抽象的程序。

您还对游戏开发人员是否会发现易于使用的RESTful API表示担忧。我会怀疑。我已经实现了许多RESTful Web服务,并帮助许多开发人员加快了构建和使用它们的速度,而掌握REST所需的概念上的飞跃对于那些沉浸在程序API中多年的人来说可能是巨大的。我认为特别是游戏开发者与程序性API的联系非常紧密,以至于尝试采用不同的范例,无论其好处如何,都可能证明是非常困难的。

答案 1 :(得分:1)

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