您是否將下一代火星漫遊器的控制API設計爲RESTful而不是RPC？

Question

請原諒我，如果這是一個「討論」問題，但我真的會 欣賞是/否的答案，並有適當的解釋。

假設你必須設計和實現一個機器人的控制API，比如說下一代 代火星車。您是否按照RESTful 原則構建了此API，或者您是否使用了經典的RPC，如XMLRPC？

我問這個，因爲我必須做類似的事情，儘管「機器人」是虛擬機的集合。我被一位頗有說服力的工程師，一位知名的REST倡導者所催促，讓API RESTful。我從來沒有使用REST原則，並且我正在努力研究它們如何適合設計低級別進程間API。 REST似乎注入了與可修改數據存儲庫進行交互的主題，通常需要多跳。我試圖做的感覺更像是密切控制機器人。我可以看到，人們可能會爭辯說，機器人在抽象上只是一個數據存儲庫 - 「向左轉」，「向外移動100米」，「獲取室外溫度」。但是這似乎是一個頗爲人爲的模型。我當然不會從緩存或代理中獲益（「你好，JPL？這是堪培拉的Akamai co-lo，我們現在接管流動站，好嗎？」）

因此，是一種RESTful架構有用嗎？當交互如此狹隘時，它是否仍然優於RPC，即使是 ？

Answer 1

我認爲REST比傳統的RPC更有意義。即使是Micorosft Robotics Studio runtime application model也使用REST。

機器人可以由URI標識的不同資源組成，包括每個傳感器和執行器或其複合抽象的一個。

REST強調保證某些方法的副作用，並且它有利於緩存，這兩方面都可用於控制和監視遙遠的機器人。僅僅因爲你可以使用REST，並不是必須是HTTP協議。

但是，像GET這樣的SAFE和IDEMPOTENT方法適用於跟蹤機器人的狀態並輪詢其傳感器數據。您可以使用諸如Last-Modified標題之類的東西來檢索不經常更改的緩存傳感器數據（例如溼度或光照水平）。

對於長途距離，您可以使用中繼代理進行緩存。

對於移動機器人的命令，在每個這樣的消息都會改變機器人的地方（例如右轉），會使用類似POST的命令。可以返回狀態碼，指示命令是立即執行還是排隊等待處理。

任何資源的絕對狀態都可以使用類似PUT的設置進行設置，其中多個消息不會僅僅改變單個消息（例如，指向北極或昏暗的前燈至10％亮度）。這允許在途中丟失消息的可能性時提供可靠的消息傳遞。

也可以通過類似POST的操作創建新資源，例如數據收集例程和一組參數。 POST請求可以發回帶有新資源的URI的CREATED結果，該資源可以在不再需要時用於刪除。

一組機器人也可能使用相同的基於REST的協議相互通話，並且可以享受相同的好處。

當然，對於像控制單個孤立本地機器人一樣簡單的事情來說，REST API可能是矯枉過正的。但對於多用戶和/或不可靠通信渠道和/或Web規模網絡，REST是需要考慮的事情。

Answer 2

REST原則確保您的應用程序可以很好地擴展，並可以與互聯網上的中介（代理，緩存等）良好地協作。如果你的「虛擬機」網絡規模很大，那麼RESTful體系結構可能是有利的。如果你正在建立一個小規模的網絡，那麼REST就不會那麼引人注目。