你会把下一代火星探测器的控制api设计成restful而不是rpc吗?

我认为rest比传统的rpc更有意义。即使是 Micorosft Robotics Studio runtime application model 使用REST。

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

rest强调保证某些方法的副作用,并且它有助于缓存,这两种方法都可以用于控制和监视远程机器人。因为你可以休息一下 不 必须是http协议。

然而,像get这样一种安全且幂等的方法对于跟踪机器人的状态和轮询其传感器数据是很好的。您可以使用类似于上次修改的头的内容来检索不经常更改的缓存传感器数据(例如湿度或光照级别)。

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

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

任何资源的绝对状态都可以使用诸如“放置”这样的方法来设置,其中多条消息不会改变任何事情,而仅仅改变一条消息(例如,指向北极或将前照灯亮度调暗到10%)。这允许可靠的消息传递,以防消息在途中丢失。

也可以通过类似于post的操作来创建新资源,例如,数据收集例程和一组参数。post请求可以用新资源的uri发回一个创建的结果,当不再需要时,可以使用该uri进行删除。

一组机器人也可以使用相同的基于rest的协议相互交谈,并且可以享受相同的好处。

诚然,对于像一个人控制一个单独的本地机器人这样的简单事情,rest api可能会被过度使用。但是对于多用户和/或不可靠的通信信道和/或Web大规模网络,REST是一个需要考虑的问题。

rest原则确保您的应用程序可以很好地扩展,并且可以很好地处理internet上的中介(代理、缓存等)。如果您的“虚拟机”网络是大规模的,那么restful架构可能是有利的。如果你正在建立一个小规模的网络,那么rest就不会那么引人注目了。