前言：
对于目前的互联网应用，分布式几乎是必备的架构。既然是分布式，不同服务之间的通讯自然就必不可少。比如淘宝就是使用了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实现
