关于RESTful，前几年就开始火了，其崛起是跟各大互联网开放平台的OPENAPI息息相关的，twitter的API就是声称完全RESTful的，不过其实呢，还是有些是伪RESTful的。那么，什么是RESTful呢？
REST很早（2000年）就有个博士（ Roy Fielding，HTTP规范的主要编写者之一）提出来了，英文全称是REpresentational State Transfer，直译过来就是表述性状态转移，看起来更像物理学概念有木有？其核心理念就是把提供服务的所有事物定义一个ID，而这个ID在HTTP服务中通常是一个URI，然后使用标准的HTTP方法（HTTP Method，比如GET, POST, PUT, DELETE, HEAD，TRACE等）来提供同一个资源的不同服务（通常就是CRUD）。至于无状态这一点，HTTP都是无状态了，实际上也可以不用去深究。
那么，RESTful究竟是怎样一种风格呢？看几个例子：
http://www.zhihu.com/people/jiacheo
http://weibo.com/1790181393/AxqXitFF6
http://weibo.com/1790181393
看出来了没有，这里的URI都是 资源URI+资源ID组成的，也就是说，我们要访问一个资源的某种服务的时候，可以直接附上ID，就能获取了，如果要修改资源呢？HTTP方法中有POST, PUT, DELETE等可以对应用来新增/修改/删除资源的操作，但是现实中，我们大多数人用的浏览器都仅支持GET和POST两个方法，所以这个时候RESTful的理念在WEB站点中就无法完美实现了。上面说到，RESTful火起来那段时间刚好是各大开放平台开始崛起的时间，因为他们的OPENAPI大多数是RESTful风格的，由于提供API比展示页面要简单很多，仅提供CRUD操作就可以实现了，这么一来，HTTP METHOD就足够用了，而且各种编程语言提供的httpclient基本也都支持这几个方法，所以RESTful能在OPENAPI中大行其道跟API的简洁性是分不开的。
不能简单的认为没有后缀名的URI就是RESTful的，也不能认为有后缀名的URI就不是RESTful的，RESTful风格不在于你有没有后缀名（RESTful的API接口中，后缀名通常是为了实现区分返回的数据格式，如xml/json等），而是在于你的URI定义是不是对应到一个资源（这里通常是个名词），而不是一个操作（通常是动词）。由于浏览器不支持更多的HTTP方法，所以伪RESTful诞生了。
怎样的URI是伪RESTful呢？比如说这个：
http://www.zhihu.com/people/edit
这个是以动词结尾的URI，定位到的不是一个资源，而是一个动作（编辑），这个页面主要是用于编辑个人资料的时候使用的，如果要RESTful化，该怎么设计呢？
http://www.zhihu.com/people?to=edit
谁说RESTful不能有URL参数的?没有参数你如何实现复杂的查询(query)?
上面说到twitter的api中也有伪RESTful的，咱们来瞧瞧：
http://api.twitter.com/users/show.format
这里的URI是定位到show这个动作，然后传入的参数是用户的ID, 实际上, 如果遵循RESTful风格的话，可以这么搞
http://api.twitter.com/users/id.format 或者 http://api.twitter.com/users.format?id=
伪RESTful也是有存在的价值的，由于浏览器的原因，仅通过HTTP方法无法支持所有的资源的操作，那么何不把对资源的操作也定义一个URI呢？这样一来，伪RESTful其实对网站的开发者更友好，因为他一看这个URI就能知道对应后台的controller（MVC中的C）中的哪一个处理器，在写代码，调试的时候也有优势，不用去看POST的参数中对应的action（动作）究竟是谁，直接就知道了。
那么RESTful与伪RESTful孰优孰劣呢？其实没有什么定论，适合就好，管他是不是RESTful呢（你是处女座？当我没说）！但是当你在对外宣称你提供的API是标准的RESTful风格的时候，就要好好审视一下自己的API是不是标准的RESTful风格了。
国内的网站RESTful风格的也有，比如新浪微博，他的访问页面基本上都是标准的RESTful风格的（修改数据的URL我没研究，不能下定论）所以关于RESTful与伪RESTful，你是怎么看的呢？
test comment