RESTful还是基于HTTP的RPC实现

前言：

对于目前的互联网应用，分布式几乎是必备的架构。既然是分布式，不同服务之间的通讯自然就必不可少。比如淘宝就是使用了HSF框架以及消息中间件notify，metaQ。不过，分布式的规模要达到淘宝这种量级的恐怕并不多。所以大部分应该还是使用较为简单的一些实现方法。

比如说，这个RESTful风格。从网上的资料大概知道，它首次出现在 2000 年 Roy Fielding 的博士论文中，他是 HTTP 规范的主要编写者之一。

对于HTTP来作为通讯，我认为是一个不错的方案，因为目前大多语言的标准库应该都是提供了HTTP的支持，而且HTTP这种无状态的请求，也容易接受。比起Socket通信，相对要易用，而且测试也比较方便甚至可以直接用浏览器来访问。

不过，对于RESTful，我并不是非常喜欢，总感觉它有点别扭。

什么是RESTful：

一种软件架构风格，设计风格而不是标准，只是提供了一组设计原则和约束条件。它主要用于客户端和服务器交互类的软件。基于这个风格设计的软件可以更简洁，更有层次，更易于实现缓存等机制。

在 REST 样式的 Web 服务中，每个资源都有一个地址。资源本身都是方法调用的目标，方法列表对所有资源都是一样的。这些方法都是标准方法，包括 HTTP GET、POST、PUT、DELETE，还可能包括 HEADER 和 OPTIONS。

它的一个重点在于，充分利用了HTTP的POST，PUT，DELETE等方法的含义。

关于RPC：

RPC（Remote Procedure Call Protocol）就是远程调用。远程调用免不了消息通信，所以本质上都是一种通信。RPC应该有各种各样的协议，基于或扩展与socket，HTTP等协议。前面说了，如果不是为了速度，应该不大会有人用socket，毕竟略有开发难度。比如淘宝的HSF也是基于HTTP的通信。

所以，最简单的想法，应该就是把HTTP协议当做RPC来用。比如我们把网址作为一个借口，传入的参数作为函数参数，response的数据作为返回信息。这其实就是一个调用。

所以，我一直不明白的是，用这种接口和一般的函数库调用一样，感觉很容易理解。而且目前的消息通信，用json基本可以通用。为什么还需要RESTful这种协议呢？

二者对比：

对于面向对象：

我觉得RESTful和RPC最大的区别应该就是面向对象了。对于RESTful而言，这个链接其实就是个对象，我可以增删改查，这些东西是HTTP自带的。

但似乎更多的操作我们没法通过这几个方法来描述呢，那不就又落回到RPC了么。

对于开发难度：

我觉得可能很多人只知道GET和POST，因为现在最常用的就是GET和POST了。虽说这应该是违背了HTTP设计的初衷。

如果我们用上RESTful，那么开发者就需要理解另外几种不常用的方法。当然，如果你说可以有现成的库啊，那当我没说。

对于返回值：

RESTful使用了HTTP的4xx，5xx的那些错误定义。相当于HTTP定义了这些错误，供开发者识别。

但实际上，业务肯定会自己定义错误标示。那么，你不觉得那些编号反而会有干扰。不知道的还以为是网络连接有问题，没想到只是请求错误。

转载请注明：旅途@KryptosX » RESTful还是基于HTTP的RPC实现