一、RESTFul介绍
1.一种软件架构风格，设计风格而不是标准，只是提供了一组设计原则和约束条件。它主要用于客户端和服务器交互类的软件。基于这个风格设计的软件可以更简洁，更有层次，更易于实现缓存等机制。
REST（英文：Representational State Transfer，简称REST）描述了一个架构样式的网络系统，比如 web 应用程序。它首次出现在 2000 年 Roy Fielding 的博士论文中，他是 HTTP 规范的主要编写者之一。在目前主流的三种Web服务交互方案中，REST相比于SOAP（Simple Object Access protocol，简单对象访问协议）以及XML-RPC更加简单明了，无论是对URL的处理还是对Payload的编码，REST都倾向于用更加简单轻量的方法设计和实现。值得注意的是REST并没有一个明确的标准，而更像是一种设计的风格。
原则条件
REST 指的是一组架构约束条件和原则。满足这些约束条件和原则的应用程序或设计就是 RESTful。Web 应用程序最重要的 REST 原则是，客户端和服务器之间的交互在请求之间是无状态的。从客户端到服务器的每个请求都必须包含理解请求所必需的信息。如果服务器在请求之间的任何时间点重启，客户端不会得到通知。此外，无状态请求可以由任何可用服务器回答，这十分适合云计算之类的环境。客户端可以缓存数据以改进性能。在服务器端，应用程序状态和功能可以分为各种资源。资源是一个有趣的概念实体，它向客户端公开。资源的例子有：应用程序对象、数据库记录、算法等等。每个资源都使用 URI (Universal Resource Identifier) 得到一个唯一的地址。所有资源都共享统一的接口，以便在客户端和服务器之间传输状态。使用的是标准的 HTTP 方法，比如 GET、PUT、POST 和 DELETE。Hypermedia 是应用程序状态的引擎，资源表示通过超链接互联。
2.REST(Representational State Transfer表述性状态转移)是一种针对网络应用的设计和开发方式，可以降低开发的复杂性，提高系统的可伸缩性。REST提出了一些设计概念和准则：1、网络上的所有事物都被抽象为资源（resource）；2、每个资源对应一个唯一的资源标识（resource identifier）；3、通过通用的连接器接口（generic connector interface）对资源进行操作；4、对资源的各种操作不会改变资源标识；5、所有的操作都是无状态的（stateless）。需要注意的是，REST是设计风格而不是标准。REST通常基于使用HTTP，URI，和XML以及HTML这些现有的广泛流行的协议和标准。
传统的请求模式和REST模式的请求模式区别：
| 作用 | 传统模式 | REST模式 |
|---|---|---|
| 列举出所有的用户 | GET /users/list | GET /users |
| 列出ID为1的用户信息 | GET /users/show/id/1 | GET /users/1 |
| 插入一个新的用户 | POST /users/add | POST /users |
| 更新ID为1的用户信息 | POST /users/mdy/id/1 | PUT /users/1 |
| 删除ID为1的用户 | POST /users/delete/id/1 | DELETE /users/1 |
关于更多的REST信息，可以参考：
二.使用RESTFul的好处 a.我理解你的问题应该是“把传统的PHP Web接口改成符合RESTful风格的Web接口有什么用处？”其实，这里最好用“好处”这个词来代替“用处”，因为传统的Web接口实现方式同样能够实现业务需要（所以这不是一个必须的事情，需要自己根据业务需求综合判断是否需要采用），而改用“RESTful风格”会有一些额外的“好处”：
统一的风格能够让各方更加便利的进行交互，也带来了更好的兼容性（这是一个所有遵循一定规范所带来的共通的好处，就像大家都说普通话，交流起来多方便啊）
对资源的操作正好对应相应的HTTP动作（GET、POST、PUT、DELETE），而这些动作正好可以满足我们对资源状态进行操作的需要，也就是说想对资源状态进行什么样的操作就选择什么样的动作，而这些动作又是HTTP协议本身提供的，多么和谐自然啊（就是题主的摘录内容）
请求所造成的影响明确，或者说副作用明确，比如GET肯定是安全的，PUT和DELETE肯定是幂等得，POST肯定是不安全的（这里的肯定是建立在API设计完全遵循“RESTful风格”基础上的）
良好的符合“RESTful风格”的URI设计，可以让Web接口的功能和整体结构更加清晰，仅仅通过URI就能方便的推测出来接口是做什么的，以及多个资源之间关联性
利用HTTP内容协商（content negotiation）实现资源的多重表述，比如请求方可以把自己需要的格式放到头信息的Accept字段中表述（如Accept: text/json），这样同样一个URI就可以输出多种格式而不再需要在URI里面特别加上一个type=json的参数了
客户端、代理服务器等可以根据HTTP协议规范进行相应的额外处理，比如Cache
... 可能还有我没总结到的好处(当然也会有一些不足~~)
上述，主要是列举了“RESTful风格”与传统设计比较带来的好处，但是最重要并让RESTful流行起来的原因，应该是RESTful在实现网络服务（Web service）方面比XML-RPC/SOAP等协议更加轻量级、拥有更好的透明性和伸缩性所致，这个就又可以解释很多了，不再赘述，推荐下面2偏文章供继续深入了解。
b.RESTFul为什么流行？说白了就一个原因：简单。
对API consumer来说，开发调试RESTFul API只需要有curl就好。
相比SOAP来说，没有client code自动生成。相比thrift来说，RESTFul又有HTTP协议带来的巨大overhead。
c.不明白的东西就可以暂时不碰，如果需要用到了再学。如果你有心情了解一下RESTful的话，wikipedia里面就有一堆链接，可以了解它的含义、作用、应用场景以及相关技术（比如SOAP）。
REST是HTTP层面的东西，和PHP或者任何其他语言都无关。它是一种约定俗成的HTTP请求语义的习惯，或者说开放、管理服务器资源的习惯，不是具体技术层面的东西。和所有其他的习惯、约定一样，你完全可以不遵守它，而遵守RESTful自然会带来一些优势（比如GET和PUT是idempotent的，在发起和处理请求的时候就可以少许多验证一致性的逻辑）。
一个很优秀的例子是CouchDB的RESTful API：
d.其他的回答都很好, 这里从另外一个角度简单说一下我的看法
如果你只是做一次性的项目, REST是可选项, 你只要把数据弄对了就可以了
如果你是做自己的产品, 那么为了代码的可维护性, 你也许会参考一下REST标准, 团队里面统一一下, 能REST就REST, 目的是为了减少沟通成本, 提高生产效率, 鼓舞士气(让大家都觉得自己在一个NB的团队里)
如果你是做一个开放平台的, 尤其是世界级别的开放平台比如FB和Twitter, 那么你别无选择, 全世界都在看着呢, 一个API的变化就会引发无数口水和新闻报道, 当来也可能引发bug. 这种情况请自己掂量.
个人观点: 我一般工作在第二中状态, 追求的是生产效率. 可以明确的告诉你, REST不能保证生产效率的提高, 适当使用, 看情况使用, 要学习但不要纠结.
e.我的建议是
1、换一个语言。
我现在也觉得难以置信：我在我初学PHP的一年里都没有接触到任何有关HTTP的知识。而当我写python和Node.js的时候，第二天就遇到了。逼着自己去查询资料，然后学会了。同样的问题还有，PHP初学者有几个知道：buffer，BDD，cgi等等等...2、阅读《HTTP权威指南》，一本号称阅读完月薪至少能拿到1w的书。
f.和传统SOAP相比，实现的结果是一样的，即提供web service，但就访问方式和风格上会简单很多
延伸阅读：