如果这几乎是一个“讨论”问题，请原谅我，但我真的很感激是/否的答案，并有适当的解释。
假设你必须为机器人设计和实现一个控制 API，比如下一代火星探测器。您是根据 RESTful 原则构建此 API，还是使用经典的 RPC，例如 XMLRPC？
我问这个是因为我必须做类似的事情，尽管“机器人”是虚拟机的集合。一位颇有说服力的工程师（一位著名的 REST 倡导者）敦促我让 API 成为 RESTful。我从未使用过 REST 原则，并且我正在努力了解它们如何适合设计低级进程间 API。REST 似乎融入了与可修改的数据存储库交互的主题，通常距离很远。我正在尝试做的事情更像是在密切控制一个机器人。我可以看出人们如何争辩说，抽象地说，机器人只是一个数据存储库——“PUT 左转”、“PUT 行进 100 米”、“获取外部温度”。但这似乎是一个相当做作的模型。我当然不会从缓存或代理中获得任何好处（“你好，喷气推进实验室？这是堪培拉的 Akamai co-lo。我们现在要接管 Rover，好吗？”）
那么，RESTful 架构在这里有用吗？即使交互如此狭窄，它仍然优于 RPC 吗？
我认为 REST 比传统的 RPC 更有意义。甚至Micorosft Robotics Studio 运行时应用程序模型也使用 REST。
机器人可以由 URI 标识的不同资源组成，包括一个用于每个传感器和执行器的资源或它们的复合抽象。
REST 强调保证某些方法的副作用是什么，并且它还促进了缓存，这两者对于控制和监视远程机器人之类的事情都很有用。并且仅仅因为您可以使用 REST，它不必是 HTTP 协议。
不过，像 GET 这样的安全和 IDEMPOTENT 方法对于跟踪机器人的状态和轮询其传感器数据很有用。您可以使用 Last-Modified 标头之类的内容来检索不经常更改的缓存传感器数据（例如，湿度或光照水平）。
对于长距离，您可以使用中继代理进行缓存。
对于移动机器人的命令，将使用类似 POST 的命令，其中每条此类消息都会改变机器人（例如，向右转）。可以返回一个状态代码，指示该命令是立即执行还是排队等待处理。
任何资源的绝对状态都可以使用诸如 PUT 之类的东西来设置，其中多条消息不会改变任何东西，而不仅仅是一条消息（例如，指向北极或将前灯调暗到 10% 亮度）。这允许在消息在途中丢失的情况下进行可靠的消息传递。
也可以通过类似POST 的操作来创建新资源，例如，数据收集例程和一组参数。POST 请求可以返回一个带有新资源 URI 的 CREATED 结果，当不再需要时可以使用该 URI 删除。
一组机器人也可以使用相同的基于 REST 的协议相互交谈，并享受相同的好处。
诚然，对于像一个人控制一个孤立的本地机器人这样简单的事情，REST API 可能是矫枉过正。但是对于多用户和/或不可靠的通信渠道和/或 Web 规模的网络，REST 是需要考虑的。
REST 原则确保您的应用程序可以很好地扩展，并与 Internet 上的中介（代理、缓存等）很好地配合使用。如果您的“虚拟机”网络规模很大，那么 RESTful 架构可能是有利的。如果你正在构建一个小规模的网络，那么 REST 就不会那么引人注目。