您会将下一代火星探测器的控制 API 设计为 RESTful 而不是 RPC 吗？
如果这接近于“讨论”问题，请原谅我，但我真的会 感谢是/否的回答，并附上适当的解释。
假设你必须为机器人设计并实现一个控制 API，比如说下一个 一代火星车。 您是否按照 RESTful 架构此 API 原理，还是使用经典的RPC，例如XMLRPC？
我问这个是因为我必须做类似的事情，尽管“机器人”是虚拟机的集合。 一位很有说服力的工程师（一位著名的 REST 倡导者）敦促我将 API 设为 RESTful。 我从未使用过 REST 原则，并且正在努力了解它们如何适合设计低级进程间 API。 REST 似乎融入了与可修改的数据存储库交互的主题，通常需要经过很多跳跃。 我想做的事情感觉更像是密切控制一个机器人。 我可以理解人们如何争论机器人在抽象上只是一个数据存储库——“PUT 左转”、“PUT 行驶 100 米”、“GET 外部温度”。 但这似乎是一个相当人为的模型。 我当然不会从缓存或代理中获得任何好处（“你好，JPL？这是堪培拉的 Akamai co-lo。我们现在接管 Rover，好吗？”）
那么，RESTful 架构在这里有用吗？ 它仍然优于 RPC 吗？ 当互动如此狭隘时？
Forgive me if this verges on being a "discussion" question, but I really would
appreciate a yes/no answer, with an appropriate explanation.
Suppose you have to design and implement a control API for a robot, say the next
generation Mars Rover. Do you architect this API according to RESTful
principles, or do you use a classic RPC, such as XMLRPC?
I ask this because I have to do something similar, though the "robot" is a collection of virtual machines. I'm being urged by one rather persuasive engineer, a well known REST advocate, to make the API RESTful. I've never used REST principles, and I'm struggling to see how they fit in designing low-level inter-process APIs. REST seems infused with the theme of interacting with a modifiable data repository, usually many hops away. What I'm trying to do feels more like closely controlling a robot. I can see how one could argue that the robot is, in the abstract, just a data repository -- "PUT left turn", "PUT travel 100 meters", "GET outside temperature". But this seems to be a rather contrived model. I certainly will receive no benefit from caching or a proxy ("Hello, JPL? This is the Akamai co-lo in Canberra. We're taking over the Rover now, ok?")
So, is a RESTful architecture useful here? Is it still superior to RPC even
when the interaction is so narrowly focused?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我认为 REST 比传统 RPC 更有意义。 甚至 Microrosft Robotics Studio 运行时应用程序模型也使用 REST。
机器人可以由 URI 标识的不同资源组成，包括每个传感器和执行器或其复合抽象的资源。
REST 强调保证某些方法的副作用，并且它也有利于缓存，这两者对于控制和监控远程机器人等都非常有用。 仅仅因为您可以使用 REST，它不必必须是 HTTP 协议。
不过，像 GET 这样的安全且幂等的方法非常适合跟踪机器人的状态并轮询其传感器数据。 您可以使用 Last-Modified 标头之类的内容来检索不经常更改的缓存传感器数据（例如湿度或光照水平）。
对于长距离，您可以使用中继代理进行缓存。
对于移动机器人的命令，将使用类似 POST 的命令，其中每个此类消息都会改变机器人（例如，右转）。 可以返回状态代码，指示命令是立即执行还是排队等待处理。
任何资源的绝对状态都可以使用类似 PUT 的方法来设置，其中多个消息不会改变任何事情，而不仅仅是单个消息（例如，指向北极或将前灯调暗至 10% 亮度）。 这样可以在消息可能在途中丢失的情况下实现可靠的消息传递。
新资源也可以通过类似POST 的操作来创建，例如数据收集例程和一组参数。 POST 请求可以发回带有新资源 URI 的 CREATED 结果，该结果可用于在不再需要时进行 DELETE。
一组机器人也可以使用相同的基于 REST 的协议相互交谈，并享受相同的好处。
诚然，对于一些简单的事情，比如一个人控制一个孤立的本地机器人，REST API 可能有点大材小用。 但对于多用户和/或不可靠的通信通道和/或 Web 规模的网络，REST 是需要考虑的。
I think REST would make more sense than traditional RPC. Even the Micorosft Robotics Studio runtime application model uses REST.
The robot can consist of different resources that are identified by URI, including one for each sensor and actuator or composite abstractions thereof.
REST puts emphasis on guaranteeing what the side effects of certain methods are and also it facilitates caching, both of which can be useful for something like controlling and monitoring a distant robot. And just because you can use REST it doesn't have to be the HTTP protocol.
A SAFE and IDEMPOTENT method like GET, though, is good for tracking the state of the robot and polling its sensor data. You can use something like the Last-Modified header to retrieve cached sensor data that doesn't change often (e.g., humidity or light levels).
For long distances you can use relay proxies for caching.
For commands that move the robot, something like POST would be used where every such message will change the robot (e.g., turn right ). A status code can be returned indicating whether the command was immediately executed or queued for processing.
The absolute state of any resources can be set using something like PUT where multiple messages will not change things any more than just a single message (e.g., point to north pole or dim front lights to 10% brightness). This allows for reliable messaging in case of probablity of messages getting lost en route.
A new resource may be created via a POST-like operation as well, e.g., a data-collection routine and a set of parameters. The POST request can send back a CREATED result with a URI for the new resource, which can be used to DELETE when no longer needed.
A group of robots may also speak to each other using the same REST based protocol and can enjoy the same benefits.
Granted, for something simple like one person controlling a single isolated local robot, a REST API may be overkill. But for multi-user and/or unreliable-communications-channels and/or Web-scale-networking, REST is something to consider.
REST 原则确保您的应用程序可以很好地扩展，并且可以与互联网上的中介（代理、缓存等）良好地配合。 如果您的“虚拟机”网络规模很大，那么 RESTful 架构可能会很有优势。 如果您正在构建小型网络，那么 REST 就不会那么有吸引力。
REST principles ensure that your application scales well, and plays well with intermediaries across the internet, (proxies, caching, etc). If your "virtual machine" network is large scale then a RESTful architecture could be advantageous. If you are building a small-scale network, then REST would not be as compelling.