1.为什么要写一手 RESTful 风格的 API 接口呢？

REST（Resource REpresentational State Transfer）资源表述性状态转移， 我写 RPC(Remote Procedure Call) 远程过程调用风格的 API 接口不是挺香的吗,比如这些接口名称：createBook , deleteBook , updateBook , getBook ...为什么你就只让我用**/books** 这一个接口名称，并且通过传递不同的HTTP Method分别做 CRUD 这几件事情呢？而且还要我按照 HTTP 规定的状态码来返回相应的信息呢？

正方辩手理由如下：
1.看URL就知道要什么，看HTTP Method就知道干什么，看HTTP Status Code就知道结果如何。

2.接口解偶，避免过度针对前端的UI、交互来设计接口，从而达到接口清晰可复用的目的。

3.传统 RPC 风格的接口名称太随意，导致客户端调用者经常产生疑问“这个接口到底是做啥的？我能用吗？会不会有副作用？”，对于大型项目来说，RESTfUl 风格可以作为一种 API 接口设计规范，从而统一前后端开发人员的认知，减少沟通成本。

2. RPC 风格与 RESTful 风格对比

RPC API -------------------------------------> RESTful API

GET /rest/api/getBook/:id -----> GET /rest/api/books/:id （获取一本书）

GET /rest/api/getBooks -----> GET /rest/api/books （获取所有书）

POST /rest/api/createBook -----> POST /rest/api/books （添加一本书）

POST /rest/api/updateBook -----> PUT /rest/api/books/:id （修改一本书）

POST /rest/api/deleteBook -----> DELETE /rest/api/books/:id （删除一本书）

3.对于 RESTful 风格系统的定义

下面六条准则定义了一个 REST 系统的特征：

客户-服务器（Client-Server），提供服务的服务器和使用服务的客户需要被隔离对待。

无状态（Stateless），来自客户的每一个请求必须包含服务器处理该请求所需的所有信息。换句话说，服务器端不能存储来自某个客户的某个请求中的信息，并在该客户的其他请求中使用。

可缓存（Cachable），服务器必须让客户知道请求是否可以被缓存。

分层系统（Layered System），服务器和客户之间的通信必须被这样标准化：允许服务器和客户之间的中间层（代理，网关等）可以代替服务器对客户的请求进行回应，而且这些对客户来说不需要特别支持。

统一接口（Uniform Interface），客户和服务器之间通信的方法必须是统一化的。（GET、POST、PUT、DELETE...）

支持按需代码（Code-On-Demand，可选），服务器可以提供一些代码或者脚本（Javascrpt，flash，etc）并在客户的运行环境中执行。这条准则是这些准则中唯一不必必须满足的一条。（比如客户可以在客户端下载脚本生成密码访问服务器。）

4.RESTful 成熟度模型

Level 0： 本层级的 Web 服务只是使用 HTTP 作为传输方式，实际上只是远程方法调用（RPC）的一种具体形式。SOAP 和 XML-RPC 都属于此类。

Level 1： Level 1 层级的 API 引入了资源的概念。要执行对资源的操作，客户端发出指定要执行的操作和任何参数的 POST 请求。

Level 2： Level 2 层级的 API 使用 HTTP 语法来执行操作，譬如 GET 表示获取、POST 表示创建、PUT 表示更新。如有必要，请求参数和主体指定操作的参数。这能够让服务影响 web 基础设施服务，如缓存 GET 请求。

Level 3： Level 3 层级的 API 基于 HATEOAS（Hypertext As The Engine Of Application State）原则设计，基本思想是在由 GET请求返回的资源信息中包含链接，这些链接能够执行该资源允许的操作。例如，客户端通过订单资源中包含的链接取消某一订单，GET 请求被发送去获取该订单。HATEOAS 的优点包括无需在客户端代码中写入硬链接的 URL。此外，由于资源信息中包含可允许操作的链接，客户端无需猜测在资源的当前状态下执行何种操作。

5.个人总结

  RESTful也好、RPC也好，都是一种设计风格,不是一种标准、规范，我们可以拿来作为参考，用来当作自己项目中的规范。最终目的还是为了提供统一便捷的后端服务，并且增加前后端代码的可维护性，从而提高项目的开发效率与降低维护成本。但是RESTful作为一种官方的指导，我们应尽量遵守那些准则，充分利用HTTP自身的一些特性，从而统一认知，降低认知成本。RPC也并非没有可取之处，我们不应该生搬硬套地用RESTful来解决一切接口设计问题。对于开放的资源 API 固然 RESTful 非常合适,而对于内部项目开发，可能不是特别的好用。一切问题都应该结合具体场景去思考解决方案，而不是拿着锤子找钉子。软件工程没有银弹！

参考资料：

RESTful API 最佳实践
你真的了解RESTful API吗？
怎样用通俗的语言解释REST，以及RESTful？
如何给老婆解释什么是RESTful?