我正在编写一个用作Web服务的C ++ API。 API中的函数将images / path_to_images作为输入参数，处理它们，并将一组不同的images / paths_to_images作为输出。我正在考虑实现一个REST接口，使开发人员能够将这个API用于他们的项目（独立于他们想要使用的任何语言）。但是，我理解只有当你有一个想要查询或操作的数据集合时，REST才是好的，这不是这里的情况。 [我拥有的集合具有操纵所提供数据的不同功能。]
那么，为此实现RPC接口是否更好，或者可以使用REST本身来完成？
答案 0 :(得分：1)
REST使用常用操作GET，POST，DELETE，HEAD，PUT。可以想象，这是面向数据的。但是对数据类型没有限制，也没有数据大小的限制（无论如何我都不知道）。 因此几乎可以在每个上下文中使用它（包括发送二进制数据）。 REST的一个优点是Web浏览器可以理解REST，而您的用户不需要专用的应用程序来发送请求。
RPC提供了更多可能性，也可以使用。例如，您可以定义自定义操作。 鉴于你打算做什么，不确定你需要那么大的力量。
就个人而言，我会选择REST。
这是您可能想要阅读的链接： http://www.sitepen.com/blog/2008/03/25/rest-and-rpc-relationship/
答案 1 :(得分：1)
和lcfseth一样，我也会选择REST。 REST确实是基于资源的，在您的情况下，您可能会认为没有资源可以处理。但是，这并不完全正确，系统中的图像转换器就是资源。您将图像发布到它并返回新图像。所以我只需创建一个URL，如：
POST http://example.com/image-converter
您将图像张贴到它并返回一些带有新图像路径的数组。
潜在地，你也可以：
GET http://example.com/image-converter
可以告诉您图像转换的状态（假设这是一个耗时的过程）。
这样做的好处是你重新使用开发人员熟悉的HTTP动词，界面几乎是自我记录的（当然你仍然需要记录POST调用接受和返回的格式） ）。使用RPC，您必须定义新动词并记录它们。
答案 2 :(得分：-1)
与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