Restful API的设计与实践

Restful这个名称应该很多人都不陌生，但是我发现不少人对Restful存在或多或少的理解偏差，其中不泛比较厉害的程序员，所以有必要为Restful来“正名”。

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

Restful的关键是抽取资源，使用URL与资源进行对应。这边也是多数人理解有偏差之处，即Restful应该理解为面向资源的架构风格，URL的设计应该是从资源的角度出发，而不应有任何的“动作”设计，其中单个资源共享同一个接口，而不同的“动作”通过请求的方法进行区分。这也是和RPC调用方式或RPC-Restful混合调用方式最大的不同之处。

那么为什么要使用Restful风格？有什么优势？

1、统一接口：约定大于配置，有了统一的规范，大家在接口设计时能够保证理解的一致性，这样首先便于接口的理解。另外同一资源URL一致，不同的CURD操作通过不同的Http协议方法进行区分，这样在设计上做到了简化。统一接口还有个非常容易被忽视的好处，就是方便使用Http协议自带的缓存机制对请求进行缓存操作，这样在一定程度上又提高了请求的性能。

2、无状态性：由于使用Http协议进行调用，每个请求都包含了服务器所需的全部信息，所以这种方式非常适用于异构系统之间的调用，同时也良好地支持分布式架构，可以动态地扩展服务器。这也是一个非常明显的优势。

Restful风格非常好，具体如何设计？

1、提取资源： 这一步非常关键，也是Restful的核心思想所在。在面向对象的世界里，对于资源的识别不算太难，一般情况下资源即是想要处理的对象，如果对应到表结构上面，可能就是表对应的实体java培训。例如电子商务网站上的下订单，那资源就是订单；如果是商品展示，那资源就是商品。当然这是最简单的情况，如果稍微复杂一点，比如现在是家电类的商品展示怎么办呢？那资源就是商品-家电类。像上面所述的情况，资源比较好识别，而有些情况下资源就不是那么明显了，比如登录，这是哪门子资源？这种情况确实不太好抽象，不过可以理解为登录信息资源。登录操作是对登录信息资源的新增操作。还有其它更复杂的情况，这个就得发挥面向资源的思路做进一步的抽象了。

2、URI设计： URI的设计其实与资源提取紧密相关，基本只要资源提取出来了，URI只是相应地翻译成地址就可以，有层级的资源通过分隔符进行路径区分。例如上面提到的商品展示可以是/goods，家电类商品可以/goods/elecequipt/，而登录可以是/loginInfo。

3、具体的动作： 这个严格说来并不是设计的一部分，是属于规范的一部分。因为使用Http协议，而协议中正好有相应的方法支持，所以正好使用Http协议的方法。（1）GET：获取资源的方法；（2）PUT：更新资源的方法；（3）POST:创建资源的方法；（4）DELETE：删除资源的方法。这几个 是比较常用的，还有几个不太常用的方法：（5）OPTIONS：查看资源支持哪些方法；（6）HEAD：与PUT类似，只不过HEAD只返回报头，不返回表示。
这里需要着重提一下，很多Restful-RPC混合模式可能就只会使用POST方法，这里就是混合模式与Restful风格最明显的区别之一。

4、返回结果： 返回结果包括Http请求的状态码和资源的表述。很多情况下API的返回结果使用Json或者XML格式表示，而Json是更加常用的。因为Json相比XML更加轻量，这样在传输过程中资源更小传输更快，另外Json的解析支持更广，所以解析起来非常方便。

5、缓存： Http协议是天然支持缓存的，这个也有利于性能的提升。当然服务端也可以添加缓存提高性能，这是另一个话题。缓存具体的实现在Http Header里面进行设置，例如Cache-Control、Expires。具体用法可以参见协议头描述：http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html

6、安全性： 如果资源是公开的，那也没有什么安全性可言了。但是实际情况是很多资源是有对应的“权限”进行操作的，这个时候就需要进行身份的认证，认证才能够进行相应的操作。所以安全性也是设计中很重要的一环。
那么安全性如何保证呢？在Http协议中有Authorization头可以进行相关设置，最基本的可以使用Basic方式，更加安全的加密方式使用Digest方式，更进一步提高安全性还可以使用第三方的OAuth协议进行认证，OAuth也是经常采用的方式。另外为了安全性的保证，大多数情况下还会选用https协议进行传输。