我试图在REST和JSON-RPC之间做出选择,为web应用程序开发API。它们是如何比较的?
更新2015:我发现REST在Web/HTTP上的API上更容易开发和使用,因为API可以利用客户端和服务器都理解的现有和成熟的HTTP协议。例如,API不需要任何额外的工作或设置就可以使用响应代码、报头、查询、帖子正文、缓存和许多其他特性。
我试图在REST和JSON-RPC之间做出选择,为web应用程序开发API。它们是如何比较的?
更新2015:我发现REST在Web/HTTP上的API上更容易开发和使用,因为API可以利用客户端和服务器都理解的现有和成熟的HTTP协议。例如,API不需要任何额外的工作或设置就可以使用响应代码、报头、查询、帖子正文、缓存和许多其他特性。
当前回答
我使用vdata为RPC协议: http://vdata.dekuan.org/
1、PHP和JavaScript都没问题。 2、跨源资源共享(CORS)呼叫仍然正常。
其他回答
我已经对这个问题进行了一些详细的研究,并认为纯REST的局限性太大,RPC是最好的,尽管我的大多数应用程序都是CRUD应用程序。如果您坚持使用REST,那么您最终将会挠头思考如何轻松地将另一个所需的方法添加到API中以实现某些特殊目的。在许多情况下,使用REST实现这一点的唯一方法是为它创建另一个控制器,这可能会使程序过于复杂。
如果您决定使用RPC,唯一的区别是您显式地将动词指定为URI的一部分,这是清晰的、一致的、bug较少的,而且确实没有麻烦。特别是如果你要创建一个超越简单CRUD的应用程序,RPC是唯一的选择。我对REST的纯粹主义者还有另一个问题:HTTP POST, GET, PUT, DELETE在HTTP中有明确的含义,这些含义被REST颠覆为其他含义,仅仅是因为它们在大多数时间都适用——但不是所有时间都适用。
在编程中,我很久以前就发现,试图用一件事来表示两件事,有时会让你吃不厌。我喜欢能够对几乎每个操作都使用POST,因为它提供了按方法需要发送和接收数据的自由。你不能把整个世界都放进CRUD里。
首先,HTTP-REST是一种“具象状态传输”体系结构。这意味着很多有趣的事情:
您的API将是无状态的,因此更容易设计(在复杂的自动机中很容易忘记转换),并与独立的软件部件集成。 你将被引导设计安全的读取方法,这将是容易缓存和集成。 你会被引导把写方法设计成幂等的方法,这样可以更好地处理超时。
其次,HTTP- rest完全兼容HTTP(请参阅前一部分中的“安全”和“幂等”),因此您将能够重用HTTP库(适用于所有现有语言)和HTTP反向代理,这将使您能够实现高级功能(缓存、身份验证、压缩、重定向、重写、日志记录等),而无需代码行。
最后但并非最不重要的是,根据HTTP 1.1的设计者(以及REST的发明者)的说法,使用HTTP作为RPC协议是一个巨大的错误:http://www.ics.uci.edu/~fielding/pubs/dissertation/evaluation.htm#sec_6_5_2
我使用vdata为RPC协议: http://vdata.dekuan.org/
1、PHP和JavaScript都没问题。 2、跨源资源共享(CORS)呼叫仍然正常。
如果您请求资源,那么RESTful API在设计上更好。如果您请求一些具有大量参数和复杂方法的复杂数据,而不是简单的CRUD,那么RPC是正确的方法。
如果您的服务只使用模型和GET/POST/PUT/DELETE模式就能正常工作,那么请使用纯REST。
我同意HTTP最初是为无状态应用程序设计的。
但是对于现代的、更复杂的(!)实时(web)应用程序,你想要使用Websockets(这通常意味着有状态性),为什么不同时使用呢?基于Websockets的JSON-RPC非常简单,所以你有以下好处:
在每个客户机上进行即时更新(为更新模型定义您自己的服务器到客户机RPC调用) 容易增加复杂性(尝试只使用REST制作Etherpad克隆) 如果你做得对(只添加RPC作为实时的额外功能),大多数仍然可以使用REST(除非主要功能是聊天或其他)
由于您只是在设计服务器端API,所以从定义REST模型开始,然后根据需要添加JSON-RPC支持,将RPC调用的数量保持在最低限度。
(很抱歉括号用多了)