我嘗試使用ProtoRPC，我真的很喜歡我可以輕鬆地添加方法，修改字段以及我的應用程序代碼的外觀和結構。
現在我在玩Backbone.js並且喜歡它的想法;我看到Backbone通過REST提供CRUD作爲使用遠程數據源的首選方法。
我知道它允許我重新定義Backbone.sync，使其適合我的需求。ProtoRPC＆REST
雖然，我不知道什麼是一個更好的方法加入Backbone和ProtoRPC在一起。如果我有ProtoRPC，我也不認爲我需要製作一個RESTful服務器端服務，並且它的工作非常完美。
請你分享你的想法如何更好地使這一切的東西一起工作和快樂？
REST和RPC差別很大。我建議不要嘗試將REST客戶端與RPC服務器結婚。
使用ProtoRPC，每種方法都有一個獨特的端點。每個端點都以JSON字典的形式通過HTTP POST接受格式正確的消息，並在成功時返回格式正確的響應字典和HTTP 200.使用REST，每個端點應代表一個資源或一組資源。你的HTTP動詞應該指明所需的動作，你的請求和響應主體應該填充完整的資源表示或者什麼都不填充，即使在成功的情況下，服務器的HTTP響應代碼也應該根據操作結果。
它看起來像Backbone.js會讓你滑動HTTP動詞，但否則，它期望一個REST兼容的服務器。如果您打算使用Backbone.js，則可能需要跳過ProtoRPC並使用類似appengine-rest-server的東西。
感謝您的評論。我同意嘗試加入RPC和REST並不是一個好主意。我想我應該選擇ProtoRPC並重新定義與服務器更新一起工作的Backbone方法。有可能這樣做，以便它可以與我的ProtoRPC方法一起工作。 – 2011-05-19 07:20:47
我有骨幹沒有經驗，所以我不會讓這樣的一個答案;但使用Protorpc的優勢之一是服務發現。理論上你可以寫一些能夠從你的protorpc消息定義中自動構建所有骨幹模型的東西（這可能很酷） – 2011-05-18 14:45:45