关于rest风格一些理解

前言

最近的一个项目业务逻辑比较简单，最近只是照猫画虎般的借用springMVC将自己的请求url风格换成rest风格，这样的uri的确是比以前的url具有更高的可读性，但是感觉始终没有真正理解rest风格。重新看了一些资料，将一些思考记录一下。

相关概念

rest

Representational State Transfer,中文翻译：表述性状态转移
表述指的是资源的表述，理解rest应该结合资源理解这几个单词

资源

1. 统一资源接口
   统一接口包含了一组受限的预定义的操作，和响应码。

   1. 操作
      不论什么样的资源，都是通过使用相同的接口进行资源的访问。接口应该使用标准的HTTP方法如GET，PUT和POST，并遵循这些方法的语义。如果按照HTTP方法的语义来暴露资源，那么接口将会拥有安全性和幂等性的特性。

      个人感觉这里就是减少了接口设计的自主性，使用预定义的接口，来达到规范性和统一性。

   2. 响应码
      不同于SOAP并需通过响应实体才能给出错误信息。对于rest而言，正确使用这些状态代码意味着客户端与服务器可以在一个具备较丰富语义的层次上进行沟通。 假如你不利用HTTP状态代码丰富的应用语义，那么你将错失提高重用性、增强互操作性和提升松耦合性的机会。

2. 资源表述
   这里主要说的是同种资源对外界的呈现形式有多种。比如文本资源可以采用html、xml、json等格式，图片可以使用PNG或JPG展现出来。对于同一个请求，移动端一般请求成功需要返回一个json；网页端一般可能会跳转一个jsp页面（html）。 资源的表述包括数据和描述数据的元数据，例如，HTTP头“Content-Type” 就是这样一个元数据属性。可以通过HTTP内容协商，客户端可以通过Accept头请求一种特定格式的表述，服务端则通过Content-Type告诉客户端资源的表述形式。

安全和幂等

例如GET和HEAD请求都是安全的， 无论请求多少次，都不会改变服务器状态。这种就是安全性；
而GET、HEAD、PUT和DELETE请求都是幂等的，无论对资源操作多少次， 结果总是一样的，后面的请求并不会产生比第一次更多的影响，这就是幂等性。

状态转移

客户端应用状态在服务端提供的超媒体的指引下发生变迁。服务端通过超媒体告诉客户端当前状态有哪些后续状态可以进入。 这些类似“下一页”之类的链接起的就是这种推进状态的作用–指引你如何从当前状态进入下一个可能的状态。

理解

优势(为什么要用rest风格的请求)

在我看来，rest核心是资源，当我们设计一个系统的时候，首先从资源的角度进行考虑。

面向资源最直观的感觉就是url中没有动词了，都是表示资源的名词。

1. 统一接口
   这里其实是让http回归本质，http协议本身就自带method，而且还有表示各种不同状态的返回码等等。
   当我们面向资源设计系统的时候，只要在资源层次对客户端和服务器端开放。这时候增删查改都有了统一接口，减少沟通交流成本。

2. 架构扩展-十年不会过时的软件系统架构
   著作权归作者所有。
   REST本身不是架构，只是一种架构风格，理解它的时候要参考这个架构风格出现的环境所施加的约束条件。
   REST的目的是“建立十年内不会过时的软件系统架构”，所以它具备三个特点：

   1. 状态无关 —— 确保系统的横向拓展能力
   2. 超文本驱动，Fielding的原话是”hypertext-driven” —— 确保系统的演化能力
   3. 对 resource 相关的模型建立统一的原语，例如：uri、http的method定义等 —— 确保系统能够接纳多样而又标准的客户端
      从另外一个角度看，第一条保证服务端演化，第三条保证客户端演化，第二条保证应用本身的演化，这实在是一个极具抽象能力的方案。

rest最佳实践（实践中怎么使用）

实践中一般需要解决两个问题，
1. 查询条件多，多种限制条件，分页参数等。
2. 批量操作

曾看见有人对论坛里提出rest实践：对于用户登录和用户退出这两个业务需求，REST指导下的架构和设计如何满足批量的删除、修改、新增如何满足

最佳实践

参考资料

1. RESTful WEB 服务四种操作POST/DELETE/PUT/GET
2. 理解restful架构
3. 那篇博士论文