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