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