api - 您是否会将下一代火星探测器的控制 API 设计为 RESTful 而不是 RPC？

Question

如果这几乎是一个“讨论”问题，请原谅我，但我真的会
感谢一个是/否的答案，并有适当的解释。

假设你必须为机器人设计和实现一个控制 API，比如说下一个
一代火星车。您是否根据 RESTful 架构此 API
原理，还是使用经典的 RPC，比如 XMLRPC？

我问这个是因为我必须做类似的事情，尽管“机器人”是虚拟机的集合。一位颇有说服力的工程师(一位著名的 REST 倡导者)敦促我让 API 成为 RESTful。我从来没有使用过 REST 原则，我正在努力了解它们如何适合设计低级进程间 API。 REST 似乎融入了与可修改的数据存储库交互的主题，通常距离很远。我正在尝试做的事情更像是在密切控制一个机器人。我可以看出人们怎么会争辩说，抽象地说，机器人只是一个数据存储库——“PUT 左转”、“PUT 行进 100 米”、“获取外部温度”。但这似乎是一个相当做作的模型。我当然不会从缓存或代理中获得任何好处(“你好，JPL？这是堪培拉的 Akamai co-lo。我们现在要接管 Rover，好吗？”)

那么，RESTful 架构在这里有用吗？它是否仍然优于 RPC
当交互如此狭窄时？

Answer 1

我认为 REST 比传统的 RPC 更有意义。甚至 Micorosft Robotics Studio runtime application model使用 REST。

机器人可以由 URI 标识的不同资源组成，包括一个用于每个传感器和执行器的资源或它们的复合抽象。

REST 强调保证某些方法的副作用是什么，并且它还促进了缓存，这两者对于控制和监视远程机器人之类的事情都很有用。仅仅因为你可以使用 REST 它不 必须是 HTTP 协议(protocol)。

不过，像 GET 这样的安全和 IDEMPOTENT 方法对于跟踪机器人的状态和轮询其传感器数据很有用。您可以使用 Last-Modified header 之类的内容来检索不经常更改的缓存传感器数据(例如，湿度或光照水平)。

对于长距离，您可以使用中继代理进行缓存。

对于移动机器人的命令，将使用 POST 之类的命令，其中每条此类消息都会改变机器人(例如，向右转)。可以返回一个状态代码，指示该命令是立即执行还是排队等待处理。

任何资源的绝对状态都可以使用诸如 PUT 之类的东西来设置，其中多条消息不会改变任何东西，而不仅仅是一条消息(例如，指向北极或将前灯调暗到 10% 亮度)。这允许在消息在途中丢失的情况下进行可靠的消息传递。

也可以通过类似 POST 的操作创建新资源，例如数据收集例程和一组参数。 POST 请求可以返回一个带有新资源 URI 的 CREATED 结果，当不再需要时可以使用该 URI 删除。

一组机器人也可以使用相同的基于 REST 的协议(protocol)相互交谈，并享受相同的好处。

诚然，对于像一个人控制一个孤立的本地机器人这样简单的事情，REST API 可能是矫枉过正。但是对于多用户和/或不可靠的通信 channel 和/或 Web 规模的网络，REST 是需要考虑的。