如果这是一个“讨论”问题，请原谅我，但我真的愿意 赞赏是/否答案，并给出适当的解释。
假设你必须为机器人设计和实现一个控制API，比如下一个 一代火星漫游者。您是否根据RESTful构建此API 原则，还是使用经典的RPC，比如XMLRPC？
我问这个是因为我必须做类似的事情，尽管“机器人”是虚拟机的集合。一位颇有说服力的工程师，一位着名的REST倡导者，正在敦促我使API RESTful。我从来没有使用REST原则，我很难看到它们如何适合设计低级别的进程间API。 REST似乎注入了与可修改的数据存储库交互的主题，通常很多跳。我正在尝试做的事情更像是密切控制机器人。我可以看到人们如何争辩机器人，在摘要中，只是一个数据存储库 - “PUT左转”，“PUT行程100米”，“GET外温”。但这似乎是一个相当人为的模型。我当然不会从缓存或代理中获益（“你好，JPL？这是堪培拉的Akamai合作伙伴。我们现在正在接管罗孚，好吗？”）
那么，RESTful架构在这里有用吗？它甚至还优于RPC 当互动如此狭隘时？
答案 0 :(得分：7)
我认为REST比传统的RPC更有意义。甚至Micorosft Robotics Studio runtime application model也使用REST。
机器人可以由URI标识的不同资源组成，包括每个传感器和执行器或其复合抽象的资源。
REST强调保证某些方法的副作用，并且它还有助于缓存，这两者都可以用于控制和监视远程机器人。只是因为你可以使用REST，不必须是HTTP协议。
然而，像GET这样的SAFE和IDEMPOTENT方法有助于跟踪机器人的状态并轮询其传感器数据。您可以使用类似Last-Modified标头的内容来检索不经常更改的缓存传感器数据（例如，湿度或亮度级别）。
对于长距离，您可以使用中继代理进行缓存。
对于移动机器人的命令，将使用诸如POST之类的东西，其中每个这样的消息将改变机器人（例如，向右转）。可以返回状态代码，指示命令是立即执行还是排队等待处理。
任何资源的绝对状态都可以使用像PUT这样的东西来设置，其中多条消息不会改变任何东西而不仅仅是一条消息（例如，指向北极或昏暗的前灯到10％的亮度）。这样可以在消息可能丢失的情况下进行可靠的消息传递。
也可以通过类似POST的操作创建新资源，例如，数据收集例程和一组参数。 POST请求可以发回一个CREATED结果，其中包含新资源的URI，可以在不再需要时用于DELETE。
一组机器人也可以使用相同的基于REST的协议相互通话，并享有同样的好处。
当然，对于像控制单个孤立本地机器人这样简单的事情，REST API可能过度。但对于多用户和/或不可靠的通信渠道和/或Web规模网络，REST需要考虑。
答案 1 :(得分：1)
REST原则可确保您的应用程序可以很好地扩展，并与互联网上的中介（代理，缓存等）配合良好。如果您的“虚拟机”网络规模很大，那么RESTful架构可能是有利的。如果您正在构建一个小规模的网络，那么REST就不那么引人注目了。