基于Web的架构,实际上就是各种规范的集合,这些规范共同组成了Web架构。比如Http协议,比如客户端服务器模式,这些都是规范。
每当我们在原有规范的基础上增加新的规范,就会形成新的架构。而REST正是这样一种架构,他结合了一系列的规范,
而形成了一种新的基于Web的架构风格。
传统的Web应用大都是B/S架构,它包括了如下一些规范:
1.客户-服务器:
2.无状态性:
要求通信必须在本质上是无状态的,即从客户到服务器的每个request都必须包含理解该request所必须的所有信息。
无状态性可改善系统的可见性,可靠性,可伸缩性。
可见性即B/S双方只需要从request/response中获取对方的信息;可靠性则是因为B/S双方不需要保存对方的信息,当故障发生时,
不会发生丢失信息无法找回的状况;因为服务器很容易释放资源(处理完就释放,不需要长期保存在内存里),因此无状态性
也可以提升系统的内存周转率,系统有更好的伸缩性,当更多的请求到来时,系统可以有更多的内存可用,有更高的吞吐量。
缺点也很明显,因此不保存数据,有些数据已经发送过了,可能会需要重新发送。
3、缓存
由于无状态性导致数据的使用比较低效,因此在客户端引入了缓存,缓存却可能导致客户端与服务器的数据不一致,一定程度
上又降低了系统的可靠性。
REST在原有的架构上增加了三个新规范:统一接口、分层系统和按需代码。
1、统一接口:
组件之间使用统一的接口,网络上所有的事物都被抽象为资源,可以用一个unique URL/URI标识。
2、分层系统:
改善各层次之间的独立性。
3、按需代码
【REST的设计准则】
REST架构是针对Web应用而设计的,其目的是为了降低开发的复杂性,提高系统的可伸缩性。REST提出了如下设计准则:
1、网络上的所有事物都被抽象为资源(resource);
2、每个资源对应一个唯一的资源标识符(resource identifier);
3、通过通用的连接器接口(generic connector interface)对资源进行操作;
4、对资源的各种操作不会改变资源标识符;
5、所有的操作都是无状态的(stateless)。
REST是基于Http协议的,任何对资源的操作行为都是通过Http协议来实现。以往的Web开发大多数用的都是Http协议中的GET和POST方法,
对其他方法很少使用,这实际上是因为对Http协议认识片面的理解造成的。
Http把对一个资源的操作限制在4个方法以内:GET,POST,PUT和DELETE。由于资源和URI是一一对应的,执行这些操作的时候URI是 没有变化的,这和以往的Web开发有很大的区别。正由于这一点,极大的简化了Web开发,也使得URI可以被设计成更为直观的反映资源的结构,这种URI的设计被称作RESTful的URI。
既然REST这么好用,那么是不是所有的Web应用都能采取此种架构呢?答案是否定的。我们知道,直到现在为止,MVC(Model-View-Controller)模式依然是Web开发最普遍的模式,
绝大多数的公司和开发人员都采取此种架构来开发Web应用,并且其思维方式也停留于此。MVC模式由数据,视图和控制器构成,通过事件(Event)触发Controller来改变Model和View。
加上Webwork,Struts等开源框架的加入,MVC开发模式已经相当成熟,其思想根本就是基于Action来驱动。
并且REST新的思维方式是把所有用户需求抽象为资源,这在实际开发中是比较难做到的,因为并不是所有的用户需求都能被抽象为资源,这样也就是说不是整个系统的结构都能通过
REST的来表现。所以在开发中,我们需要根据以上2点来在REST和MVC中做出选择。我们认为比较好的办法是混用REST和MVC,因为这适合绝大多数的Web应用开发,开发人员只需要对比较
容易能够抽象为资源的用户需求采取REST的开发模式,而对其它需求采取MVC开发即可。
每当我们在原有规范的基础上增加新的规范,就会形成新的架构。而REST正是这样一种架构,他结合了一系列的规范,
而形成了一种新的基于Web的架构风格。
传统的Web应用大都是B/S架构,它包括了如下一些规范:
1.客户-服务器:
2.无状态性:
要求通信必须在本质上是无状态的,即从客户到服务器的每个request都必须包含理解该request所必须的所有信息。
无状态性可改善系统的可见性,可靠性,可伸缩性。
可见性即B/S双方只需要从request/response中获取对方的信息;可靠性则是因为B/S双方不需要保存对方的信息,当故障发生时,
不会发生丢失信息无法找回的状况;因为服务器很容易释放资源(处理完就释放,不需要长期保存在内存里),因此无状态性
也可以提升系统的内存周转率,系统有更好的伸缩性,当更多的请求到来时,系统可以有更多的内存可用,有更高的吞吐量。
缺点也很明显,因此不保存数据,有些数据已经发送过了,可能会需要重新发送。
3、缓存
由于无状态性导致数据的使用比较低效,因此在客户端引入了缓存,缓存却可能导致客户端与服务器的数据不一致,一定程度
上又降低了系统的可靠性。
REST在原有的架构上增加了三个新规范:统一接口、分层系统和按需代码。
1、统一接口:
组件之间使用统一的接口,网络上所有的事物都被抽象为资源,可以用一个unique URL/URI标识。
2、分层系统:
改善各层次之间的独立性。
3、按需代码
【REST的设计准则】
REST架构是针对Web应用而设计的,其目的是为了降低开发的复杂性,提高系统的可伸缩性。REST提出了如下设计准则:
1、网络上的所有事物都被抽象为资源(resource);
2、每个资源对应一个唯一的资源标识符(resource identifier);
3、通过通用的连接器接口(generic connector interface)对资源进行操作;
4、对资源的各种操作不会改变资源标识符;
5、所有的操作都是无状态的(stateless)。
REST是基于Http协议的,任何对资源的操作行为都是通过Http协议来实现。以往的Web开发大多数用的都是Http协议中的GET和POST方法,
对其他方法很少使用,这实际上是因为对Http协议认识片面的理解造成的。
Http把对一个资源的操作限制在4个方法以内:GET,POST,PUT和DELETE。由于资源和URI是一一对应的,执行这些操作的时候URI是 没有变化的,这和以往的Web开发有很大的区别。正由于这一点,极大的简化了Web开发,也使得URI可以被设计成更为直观的反映资源的结构,这种URI的设计被称作RESTful的URI。
既然REST这么好用,那么是不是所有的Web应用都能采取此种架构呢?答案是否定的。我们知道,直到现在为止,MVC(Model-View-Controller)模式依然是Web开发最普遍的模式,
绝大多数的公司和开发人员都采取此种架构来开发Web应用,并且其思维方式也停留于此。MVC模式由数据,视图和控制器构成,通过事件(Event)触发Controller来改变Model和View。
加上Webwork,Struts等开源框架的加入,MVC开发模式已经相当成熟,其思想根本就是基于Action来驱动。
并且REST新的思维方式是把所有用户需求抽象为资源,这在实际开发中是比较难做到的,因为并不是所有的用户需求都能被抽象为资源,这样也就是说不是整个系统的结构都能通过
REST的来表现。所以在开发中,我们需要根据以上2点来在REST和MVC中做出选择。我们认为比较好的办法是混用REST和MVC,因为这适合绝大多数的Web应用开发,开发人员只需要对比较
容易能够抽象为资源的用户需求采取REST的开发模式,而对其它需求采取MVC开发即可。