我正在编写一个用作 Web 服务的 C++ API。 API 中的函数将 images/path_to_images 作为输入参数，对其进行处理，并给出一组不同的 images/paths_to_images 作为输出。我正在考虑实现一个 REST 接口，以使开发人员能够将这个 API 用于他们的项目（独立于他们想要使用的任何语言）。但是，我知道 REST 仅在您拥有要查询或操作的数据集合时才是好的，这里并非完全如此。 [我拥有的集合具有操纵所提供数据的不同功能。]
那么，我最好为此实现一个 RPC 接口，还是可以使用 REST 本身来完成？
【问题讨论】：
相对于 RPC，REST（json 风格的接口）是轻量级的，API 用户易于使用。 RPC(soap/xml) 看起来很复杂很重。
我猜你想要的是基于 HTTP+JSON 的 API，而不是 REST 作者声称的 REST API http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven
【讨论】：
REST 使用常用操作 GET,POST,DELETE,HEAD,PUT。可以想象，这是非常面向数据的。但是，对数据类型没有限制，对数据的大小也没有限制（无论如何我都不知道）。 因此几乎可以在所有情况下使用它（包括发送二进制数据）。 REST 的优点之一是 Web 浏览器可以理解 REST，并且您的用户不需要专门的应用程序来发送请求。
RPC 提供了更多的可能性，也可以使用。例如，您可以定义自定义操作。 考虑到您打算做什么，不确定您是否需要这么大的力量。
我个人会选择 REST。
这是您可能想阅读的链接： http://www.sitepen.com/blog/2008/03/25/rest-and-rpc-relationship/
【讨论】：
和 lcfseth 一样，我也会选择 REST。 REST 确实是基于资源的，在您的情况下，您可能会认为没有资源可以处理。但是，这并不完全正确，系统中的图像转换器就是资源。您将图像发布到它，它会返回新图像。所以我只需创建一个 URL，例如：
POST http://example.com/image-converter
您将图像发布到它，它会返回一些包含新图像路径的数组。
您还可以：
GET http://example.com/image-converter
它可以告诉您图像转换的状态（假设这是一个耗时的过程）。
这样做的好处是您可以重复使用开发人员熟悉的 HTTP 动词，界面几乎是自记录的（当然您仍然需要记录 POST 调用接受和返回的格式)。使用 RPC，您必须定义新动词并记录它们。
【讨论】：
http://example.com/image-converter 从您的示例链接到我拥有的 C++ 代码？