利用Restlet开发的研究--Restlet的背景

1.1、Servlet的问题

1）没有对协议与应用之间的关系进行清晰的划分；

2）由于在设计Servlet时存在对阻塞IO的假设，故不能充分利用非阻塞NIO机制；

3）所有的Servlet Web容器对于某些应用来讲是过渡设计的；

4）Servlet API鼓励应用开发者在应用或用户会话级别直接将session状态保存在内存中，造成了Servlet容器扩展性和高可用性的问题。为了解决这些问题就要实现复杂的负载均衡、session复制、持久化机制。从而导致了可扩展性必须成为灾难。

 

举个例子，URI模式和它的处理者（handler）之间的映射是受限制的，而且其配置都集中在一个配置文件中。还有，它把socket流的控制直接交给了应用系统开发人员，Servlet容器阻碍了我们充分使用NIO特性对IO操作进行优化。最后，他对一些HTTP特性，例如缓存、内容协商以及内容压缩支持的不好。这对开发人员来说是件痛苦的事，因为这阻碍了他们将精力集中在应用系统相关的代码上。

 

Java EE Stack中新的HTTP客户端API的缺少。JDK的HttpURLConnection类很难用，而且许多HTTP特性都不支持，比如为内容协商而表达的客户端选择等。人们经常需要依赖第三方HTTP客户端API突破这些限制。但是，HttpURLConnection不支持NIO。

 

1.2、表述性状态转移（REST，即Representational State Transfer）

1.2.1、理解Resource

我们来看看Wikipedia这张图，这个三角形是在讲解Resource最重要的三个东西，Nouns，Verb，Content Type。

 

Nouns

在网络上，每个URL带给我们的意义其实就是代表各式各样的资源（Resource），有些可能代表你的个人日志，有些代表我出去玩的图片，有些代表你最喜欢的歌手的音乐，有些代表你朋友搞笑的影片。

 

Resource里面，Nouns其实是一个URL，它代表网络上面Resource的唯一的地址，同一个Resource理论上来说，应该只有一个URL代表这个Resource。用超过一个URL来代表同一个Resource是不好的方式。

 

Content Types

刚刚说过URL代表Resource的地址，但Resource其实跟大家想的有点不太一样，Resource不只是代表一个档案，也代表了一个概念。

举了例子，这个图片（里面是我的邮箱）：

这个是一个png图片，地址在http://******/mail.png，但是如果把图转换成jpg，地址就变为http://******/mail.jpg。虽然两个URL不同，但对我们来说，意义都是一样的。

 

所以，尽管格式不同，它们依旧是一个Resource，而这些格式就是Content Types。

 

假设有一个XML文件http://******/mail.xml，这个XML里也记录着我的Email：

<xml>

<email>zehao.wang at gmail dot com</email>

</xml>

 

这跟上面的图还是同一个Resource，虽然格式不同，但记录了同样的意义。

 

在Web上面，Resource是一个概念，而不仅仅是一个档案。一个Resource可能有各种不同的Content Type，但依旧代表的是同一个Resource。

 

Verbs

至于三角形的最后一角Verbs，就是操作Resource的方式。

 

Web用宏观来说，其实就是一个超大的数据库，里面有各式各样不同的Resource，每个URL 都是指向各种不同的Resource，我们每天上网，其实都是借HTTP来请求各式各样不同的Resource。

 

既然Web根本就是一个网络上面Resource的数据库，每个Resource都是跟数据库里面的Data Entry类似，那么有用过数据库的人都知道，我们每天对数据库的每个Data Entry做个中操作，也就是经典的CRUD（Create、Read、Update、Delete），尽管我们对数据库的操作很多，但都超不出CRUD这四个动作。

 

RFC 2616里面讲到，HTTP 1.1一共有八个method，里面有两个Method是大家不可能不懂的（GET和POST），虽然HTTP定义八个Method之多，但是大家在Coding Web时只使用这两个Method。

 

原因很简单，因为很多人使用的HTTP Client，也就是Browser，只支援GET和POST。所以，我们之前的Coding，都是只用GET和POST来对Web Resource做CRUD。

 

我们必须用部分的URL来表示我们对这个Resource的操作，这样做也没有什么不好，但要知道URL其实是要制定Resource位置的，URL不是拿来表示Verbs的。而且这样做等于我们使用四个URL来表示同一个Resource，这跟一个Resource理论上来说只能有一个URL抵触。

 

RFC定义的HTTP1.1里面，其实有四个Method是直接Mapping到CRUD的，那就是GET、POST、PUT、DELETE。既然HTTP1.1已经有对应好的Method，那为什么我们要舍近求远，硬是要使用GET、POST来设计出CRUD，为什么不原来就规定好的Mapping来做CURD呢？

 

没错，这就是REST，让大家不需要再舍近求远，不需要用非Web Standard的方式来做Web Development。

 

1.2.2、REST的定义

Representational state transfer ( REST ) is a style of software architecture for distributed hypermedia systems 

such as the World Wide Web . As such, it is not strictly a method for building what are sometimes called 

" web services ." The terms “representational state transfer” and “REST” were introduced in 2000 in the 

doctoral dissertation of Roy Fielding , one of the principal authors of the Hypertext Transfer Protocol (HTTP) 

specification. The terms have since come into widespread use in the networking community. 

 

在定义上来说，REST并不等于HTTP，REST是一种Architectural Style，而非一种Standard，所以REST并没有toolkit，也没有W3C Spec。相对起来，HTTP 才是一种Standard，有相對應的toolkit，W3C Spec。HTTP是一种REST的实做，也是最成功的实做。但是我们以实用为主，并不是那么在乎太过细部的差别，所以以后我不会太强调REST跟HTTP两者意义上的区分。

 

1.2.3、REST的设计准则

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

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

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

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

4）对资源的各种操作不会改变资源操作符；

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

 

1.2.4、Web应用规范及REST新增规范

客户——服务器

这种规范的提出，改善了用户接口跨多个平台的可移植性，并且通过简化服务器组件，改善了系统的可伸缩性。最为关键的是通过分离用户接口和数据存储这两个关注点，使得不同用户终端享受相同数据成为了可能。

 

无状态性

无状态性是在客户——服务器约束的基础上添加的又一层规范。它要求通信必须在本质上是无状态的，即从客户到服务器的每个request都必须包含理解该request所必须的所有信息。

 

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

 

缓存

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

 

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

 

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

 

统一接口

REST架构风格的核心特征就是强调组件之间有一个统一的接口，这表现在REST世界里，网络上所有的事物都被抽象为资源，而REST就是通过通用的链接器接口对资源进行操作。

 

这样设计的好处是保证系统提供的服务都是解耦的，极大的简化了系统，从而改善了系统的交互性和可重用性。并且REST针对Web的常见情况做了优化，使得REST接口被设计为可以高效的转移大粒度的超媒体数据，这也就导致了REST接口对其它的架构并不是最优的。

 

分层系统

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

 

按需代码

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

 

1.2.5、REST的宗旨

REST从资源的角度来观察整个网络，分布在各处的资源由URI确定，而客户端的应用通过URI来获取资源的表形。获得这些表形致使这些应用程序转变了其状态。随着不断获取资源的表形，客户端应用不断地在转变着其状态，所谓表形化的状态转变（Representational State Transfer）。

 

1.2.6、REST的要点及标准

需要注意的是，REST是一种设计风格而不是一个标准。REST通常基于使用HTTP，URI，和XML以及HTML这些现有的广泛流行的协议和标准。

1）资源是由URI来制定；

2）对资源的操作包括获取、创建、修改和删除，这些曹作正好对应HTTP协议提供的GET、POST、PUT和DELETE方法；

3）通过操作资源的表形来操作资源；

4）资源的表现形式则是XML或HTML，取决于读者是机器还是人，消费Web服务的客户软件还是Web浏览器。当然也可以是任何其他的格式。

 

1.2.7、REST的要求

1）客户端和服务器结构；

2）连接协议具有无状态性；

3）能够利用Cache机制增进性能；

4）层次化的系统；

5）Code On Demand — JavaScript。

 

1.2.8、REST的优点

1）可以利用缓存Cache来提高响应速度；

2）通讯本身的无状态性可以让不同的服务器处理一系列请求中的不同请求，提高服务器的扩展性；

3）浏览器即可作为客户端，简化软件需求；

4）相对与其他叠加在HTTP协议之上的机制，REST的软件依赖性更小；

5）不需要额外的资源发现机制；

6）在软件技术演进中，长期的兼容性更好。

 

1.3、Restlet简介

1.3.1、Restlet简介

Restlet是一个Java下的轻量级REST框架。通过拥抱REST，它模糊了Web站点和Web服务之间的界限，从而帮助开发人员构建Web应用。每一个主要的REST概念（REST concept）都有一个对应的Java类。你的REST化的Web设计和你的代码之间的映射是非常简单直接的。

 

Restlet是一个以CDDL或GPL发布的开源项目。该项目包含一个Restlet API，一个引用实现（Noelios Restlet引擎）以及一套扩展。

 

1.3.2、为什么使用Restlet

Restlet在REST原则下设计一个新的API。第一次，我们有了统一Web应用客户端和服务器端的机会，这个API完全支持NIO并能让开发人员编程控制Web容器、连接器（connector）等，而且不需要经常性的依赖XML描述符就能部署应用系统。

 

1.3.3、Restlet的优缺点

优点：

1）有内建的HTTP认证机制，不需要另外开发安全机制；

2）灵活性较高，支持更多的REST概念，支持透明的内容协商，适合开发更加强大的REST组件（不限于服务器端应用）；

3）零配置文件，全部配置通过代码来完成。