原型 RPC 和 REST答案

【问题标题】：ProtoRPC & REST原型 RPC 和 REST
【发布时间】：2011-08-27 19:47:21
【问题描述】：

我尝试使用 ProtoRPC，我真的很喜欢我可以轻松地添加方法、修改字段，以及我的应用程序代码看起来如此稳固和结构化。
现在我在玩Backbone.js 并且喜欢它的想法；我看到 Backbone 通过 REST 提供 CRUD 作为处理远程数据源的首选方法。
我知道它允许我重新定义 Backbone.sync 以使其适合我的需求。

不过，我不确定将 Backbone 和 ProtoRPC 结合在一起的更好方法是什么。如果我有 ProtoRPC 并且它运行良好，我也不认为我需要创建一个 RESTful 服务器端服务。

您能否分享您的想法，如何更好地让所有这些东西一起工作并快乐？

【问题讨论】：

我没有骨干方面的经验，所以我不会回答这个问题；但是使用 Protorpc 的优点之一是服务发现。从理论上讲，您可以编写一些可以从您的 protopc 消息定义中自动构建所有主干模型的东西（这可能很酷）

标签： javascript google-app-engine rest backbone.js

【解决方案1】：

我知道有点晚了，但似乎有人为 Backbone.js 实现了 JSONRPC：

Github (Docs)

【讨论】：

【解决方案2】：

REST 和 RPC 的区别相当大。我建议不要尝试将 REST 客户端与 RPC 服务器结合。

使用 ProtoRPC，每个方法都有一个不同的端点。每个端点通过 HTTP POST 以 JSON 字典的形式接受格式正确的消息，并在成功时返回格式正确的响应字典和 HTTP 200。使用 REST，每个端点应该代表一个资源或资源集合。您的 HTTP 动词应指示所需的操作，您的请求和响应正文应填充资源的完整表示或根本不填充，并且服务器的 HTTP 响应代码（即使在成功的情况下）也应根据运算结果。

看起来 Backbone.js 可以让你在 HTTP 动词上滑动，但除此之外，它需要一个兼容 REST 的服务器。如果您打算使用 Backbone.js，您可能希望跳过 ProtoRPC 并使用类似 appengine-rest-server 的内容。

【讨论】：

感谢您的评论。我同意尝试加入 RPC 和 REST 不是一个好主意。我想我应该选择 ProtoRPC 并重新定义与服务器更新一起使用的 Backbone 方法。这样做是可能的，这样它就可以与我的 ProtoRPC 方法一起使用。