REST架构的思考

一、什么是REST

REST是英文Representational State Transfer的缩写，中文翻译为“表述性状态转移”，他是由Roy Thomas Fielding博士在他的论文 《Architectural Styles and the Design of Network-based Software Architectures》中提出的一个术语。REST本身只是为分布式超媒体系统设计的一种架构风格，而不是标准。 

二、REST规范

原有的B/S架构有两种规范：

1. 无状态性 

无状态性是在客户－服务器约束的基础上添加的又一层规范。他要求通信必须在本质上是无状态的，即从客户到服务器的每个request都必须包含理解该 request所必须的所有信息。这个规范改善了系统的可见性（无状态性使得客户端和服务器端不必保存对方的详细信息，服务器只需要处理当前 request，而不必了解所有的request历史），可靠性（无状态性减少了服务器从局部错误中恢复的任务量），可伸缩性（无状态性使得服务器端可以 很容易的释放资源，因为服务器端不必在多个request中保存状态）。同时，这种规范的缺点也是显而易见得，由于不能将状态数据保存在服务器上的共享上 下文中，因此增加了在一系列request中发送重复数据的开销,严重的降低了效率。

2. 缓存 

为了改善无状态性带来的网络的低效性，我们填加了缓存约束。缓存约束允许隐式或显式地标记一个response中的数据，这样就赋予了客户端缓存 response数据的功能，这样就可以为以后的request共用缓存的数据，部分或全部的消除一部分交互，增加了网络的效率。但是用于客户端缓存了信 息，也就同时增加了客户端与服务器数据不一致的可能，从而降低了可靠性。

B/S架构的优点是其部署非常方便，但在用户体验方面却不是很理想。为了改善这种情况，我们引入了REST。 

REST在原有的架构上增加了三个新规范：统一接口，分层系统和按需代码。

3. 统一接口 

REST 架构风格的核心特征就是强调组件之间有一个统一的接口，这表现在REST世界里，网络上所有的事物都被抽象为资源，而REST就是通过通用的链接器接口对 资源进行操作。这样设计的好处是保证系统提供的服务都是解耦的，极大的简化了系统，从而改善了系统的交互性和可重用性。并且REST针对Web的常见情况 做了优化，使得REST接口被设计为可以高效的转移大粒度的超媒体数据，这也就导致了REST接口对其它的架构并不是最优的。

4. 分层系统 

分层系统规则的加入提高了各种层次之间的独立性，为整个系统的复杂性设置了边界，通过封装遗留的服务，使新的服务器免受遗留客户端的影响，这也就提高了系统的可伸缩性。

5. 按需代码 

REST允许对客户端功能进行扩展。比如，通过下载并执行applet或脚本形式的代码，来扩展客户端功能。但这在改善系统可扩展性的同时，也降低了可见性。所以它只是REST的一个可选的约束。 

三、REST的设计准则 

REST架构是针对Web应用而设计的，其目的是为了降低开发的复杂性，提高系统的可伸缩性。REST提出了如下设计准则： 

• 网络上的所有事物都被抽象为资源（resource）； 

• 每个资源对应一个唯一的资源标识符（resource identifier）； 

• 通过通用的连接器接口（generic connector interface）对资源进行操作； 

• 对资源的各种操作不会改变资源标识符； 

• 所有的操作都是无状态的（stateless）。

注意：

1. REST中的资源所指的不是数据，而是数据和表现形式的组合，比如“最新访问的10位会员”和“最活跃的10为会员”在数据上可能有重叠或者完全相同，而 由于他们的表现形式不同，所以被归为不同的资源，这也就是为什么REST的全名是Representational State Transfer的原因。资源标识符就是URI(Uniform Resource Identifier)，不管是图片，Word还是视频文件，甚至只是一种虚拟的服务，也不管你是xml格式,txt文件格式还是其它文件格式，全部通过 URI对资源进行唯一的标识。
    

2. REST是基于Http协议的，任何对资源的操作行为都是通过Http协议来实现。以往的Web开发大多数用的都是Http协议中的GET和POST方 法，对其他方法很少使用，这实际上是因为对Http协议认识片面的理解造成的。Http不仅仅是一个简单的运载数据的协议，而是一个具有丰富内涵的网络软 件的协议。他不仅仅能对互联网资源进行唯一定位，而且还能告诉我们如何对该资源进行操作。Http把对一个资源的操作限制在4个方法以内：GET, POST,PUT和DELETE，这正是对资源CRUD操作的实现。由于资源和URI是一一对应的，执行这些操作的时候URI是没有变化的，这和以往的 Web开发有很大的区别。正由于这一点，极大的简化了Web开发，也使得URI可以被设计成更为直观的反映资源的结构，这种URI的设计被称作 RESTful的URI。这位开发人员引入了一种新的思维方式：通过URL来设计系统结构。当然了，这种设计方式对一些特定情况也是不适用的，也就是说不 是所有的URI都可以RESTful的。 

四、思考

1. 以上的信息参考自http://www.cnblogs.com/EasyLive2006/archive/2009/11/03/1595152.html并整理；

2. 对于网站开发，我们常用的操作就是GET，和POST方式，比如获取数据采用GET方式，提交数据采用POST方式，但不管是哪种方式，提交数据还是获取数据，后端都要对参数进行处理并对这些操作进行相应。而REST的架构把PUT和DELETE两种数据提交方式用上了，整个操作就会更加的清晰明了，非常的有逻辑性。

3. REST的HTTP协议操作与数据库的CURD操作对比:
   HTTP请求数据库请求GETSELECTPOSTINSERTPUTUPDATEDELETEDELETE

4. 从以上对比表来看，前端与后端的数据交互更加像是另外一层的数据库交互操作，然而，知道这个没什么卵用，这个是基于REST思想的一种HTTP协议规范，但如果后端不按照其对应的数据操作来进行处理，没有什么卵用；
   举个例子：比如采用DELETE方式发送请求，但后端却处理成增加数据或者修改数据，POST数据后端处理成删除；但是，我们目前是没有采用这种思想来进行操作的，不管是修改，删除，增加，查询，采用的都是POST或者GET方式。

5. 数据交互形式：后端返回json/xml或者其他前端所期望的数据，但不管什么数据，需要有一个明确的规范和完善的资源管理机制

6. 如果运用了REST这种设计思想，我们可以干什么呢？

1). 我们的前端服务器完全可以和数据服务器（REST服务器）分离，前端服务器处理服务器请求，加载前端骨架（这里不叫框架，叫骨架我觉得更加贴切，REST服务器上的就是肉），然后前端再更具不同的服务需求，像REST请求数据或者更具不同的操作，像REST服务器提交增删改的请求等等
2). 不过我觉得把REST叫做面向Api(接口)服务设计来说应该也是很贴切的，REST服务就是接口。
3). 有了REST服务器，不管是电脑端还是手机端，或者是APP，按照REST的接口来进行数据交互，完全不用关心后端实现，也就是说，前端和后端真正的实现了完全的分离设计。

五、后记

关于之后的信息，应该要整理一个简版的前后端代码模型来理解，这个我晚上抽点时间来理一个模型，还有几个方面需要整理：

1. 代码模型实现

2. 架构的不合理性

3. 不适合REST架构的场景

4. 其他