[转]REST 协议的认识 客户端服务端例子

转自 REST 协议的认识 客户端服务端例子

1、协议介绍：
转 http://blog.csdn.net/colorfulbinary/article/details/6657184
REST架构风格是全新的针对Web应用的开发风格，是当今世界最成功的互联网超媒体分布式系统架构，它使得人们真正理解了Http协议本来面貌。随着 REST架构成为主流技术，一种全新的互联网网络应用开发的思维方式开始流行。

目前，51，校内，海内，阿里软件等都通过REST架构来实现平台数据的开放，与第三方的数据交换。REST已然成为sns开放平台的首要开放标准。下面简单介绍一下REST的原理和使用准则。

wiki介绍见此：http://en.wikipedia.org/wiki/Representational_State_Transfer

REST是什么

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

基于Web的架构，实际上就是各种规范的集合，这些规范共同组成了Web架构。比如Http协议，比如客户端服务器模式，这些都是规范。每当我们在原有规 范的基础上增加新的规范，就会形成新的架构。而REST正是这样一种架构，他结合了一系列的规范，而形成了一种新的基于Web的架构风格。

传统的Web应用大都是B/S架构，它包括了如下一些规范 。

客户－服务器

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

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

为 了改善无状态性带来的网络的低效性，我们填加了缓存约束。缓存约束允许隐式或显式地标记一个response中的数据，这样就赋予了客户端缓存 response数据的功能，这样就可以为以后的request共用缓存的数据，部分或全部的消除一部分交互，增加了网络的效率。但是用于客户端缓存了信 息，也就同时增加了客户端与服务器数据不一致的可能，从而降低了可靠性。
B/S架构的优点是其部署非常方便，但在用户体验方面却不是很理想。为了改善这种情况，我们引入了REST。

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

统一接口

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

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

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

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

网络上的所有事物都被抽象为资源（resource）；
每个资源对应一个唯一的资源标识符（resource identifier）；
通过通用的连接器接口（generic connector interface）对资源进行操作；
对资源的各种操作不会改变资源标识符；
所有的操作都是无状态的（stateless）。
REST中的资源所指的不是数据，而是数据和表现形式的组合，比如“最新访问的10位会员”和“最活跃的10为会员”在数据上可能有重叠或者完全相同，而 由于他们的表现形式不同，所以被归为不同的资源，这也就是为什么REST的全名是Representational State Transfer的原因。资源标识符就是URI(Uniform Resource Identifier)，不管是图片，Word还是视频文件，甚至只是一种虚拟的服务，也不管你是xml格式,txt文件格式还是其它文件格式，全部通过 URI对资源进行唯一的标识。

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的。

REST 之所以可以提高系统的可伸缩性，就是因为它要求所有的操作都是无状态的。由于没有了上下文(Context)的约束，做分布式和集群的时候就更为简单，也 可以让系统更为有效的利用缓冲池(Pool）。并且由于服务器端不需要记录客户端的一系列访问，也减少了服务器端的性能。

使用REST架构

对于开发人员来 说，关心的是如何使用REST架构，这里我们来简单谈谈这个问题。REST不仅仅是一种崭新的架构，它带来的更是一种全新的Web开发过程中的思维方式： 通过URL来设计系统结构。在REST中，所有的URL都对应着资源，只要URL的设计是良好的，那么其呈现的系统结构也就是良好的。这点和TDD (Test Driven Development)很相似，他是通过测试用例来设计系统的接口，每一个测试用例都表示一系列用户的需求。开发人员不需要一开始就编写功能，而只需要 把需要实现的功能通过测试用例的形式表现出来即可。这个和REST中通过URL设计系统结构的方式类似，我们只需要根据需求设计出合理地URL，这些 URL不一定非要链接到指定的页面或者完成一些行为，只要它们能够直观的表现出系统的用户接口。根据这些URL，我们就可以方便的设计系统结构。从 REST架构的概念上来看，所有能够被抽象成资源的东西都可以被指定为一个URL，而开发人员所需要做的工作就是如何能把用户需求抽象为资源，以及如何抽 象的精确。因为对资源抽象的越为精确，对REST的应用来说就越好。这个和传统MVC开发模式中基于Action的思想差别就非常大。设计良好的URL， 不但对于开发人员来说可以更明确的认识系统结构，对使用者来说也方便记忆和识别资源，因为URL足够简单和有意义。按照以往的设计模式，很多URL后面都 是一堆参数，对于使用者来说也是很不方便的。

既然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开发即可。这里需要提到的就 是ROR(Ruby on Rails)框架，这是一个基于Ruby语言的越来越流行的Web开发框架，它极大的提高了Web开发的速度。更为重要的是，ROR(从1.2版本起)框 架是第一个引入REST做为核心思想的Web开发框架，它提供了对REST最好的支持，也是当今最成功的应用REST的Web开发框架。实际上，ROR的 REST实现就是REST和MVC混用，开发人员采用ROR框架，可以更快更好的构建Web应用。

对开发人员来说，REST不仅仅在Web开发上贡献了自己的力量，同时也让我们学到了如何把软件工程原则系统地应用于对一个真实软件的设计和评估上

2、谈谈自己对REST的认识
REST协议其实和其他的soap协议大致相同，
服务端：有点类似于我们所知道的servlet服务
客户端：可以使用get 、post带上xml的结构体 于服务端进行通讯

网上开源的REST框架也有很多 ，如Restlet 、RichRest 、RESTEasy 、sqlrest-1.0

框架介绍：http://blog.163.com/java_moon/blog/static/13333826420091110105010510/
目前宣称支持REST的Java框架包括以下这些：
Restlet（http://www.restlet.org/）
Cetia4（https://cetia4.dev.java.net/）
Apache Axis2（http://http://ws.apache.org/axis2/）
sqlREST（http://sqlrest.sourceforge.net/）
REST-art（http://rest-art.sourceforge.net/）
以下对这些框架进行了较为全面的分析。
Restlet，最新版本1.0.1
特点：完全抛弃了Servlet API，作为替代，自己实现了一套API。能够支持复杂的REST架构设计。
缺点：

1. 虽然也可以运行于Web容器中，但是难以利用Servlet和JSP等资源。因为需要另外学习一套API和概念，学习成本比较高。
2. 完全不支持服务器端的HTTP Session，强制完全基于无状态服务器模型来做开发。对于基于浏览器的应用来说，开发难度较高。
3. 自身没有包括与Spring的集成，可以使用第三方代码与Spring集成，集成难度较大。
4. 文档不是很丰富，大多比较简短，很多时候需要自己去读代码，或者到其wiki上去查找。
5. 没有内建的国际化支持。
   优点：
6. 有内建的HTTP认证机制，不需要另外开发安全机制。
7. 灵活性较高，支持更多的REST概念，支持透明的内容协商，适合于开发更加强大的REST组件（不限于服务器端应用）。
8. 零配置文件，全部配置通过代码来完成。
   相关资源：
   功能列表：http://www.restlet.org/about/features
   简介：http://www.restlet.org/about/introduction
   教程：http://www.restlet.org/documentation/1.0/tutorial
   FAQ：http://www.restlet.org/about/faq
   Cetia4，最新版本1.0
   特点：基于Servlet API开发，可以运行于所有的Web容器中。
   优点：
9. 可以充分利用Servlet API和JSP等资源，需要额外学习的概念较少，学习成本较低。
10. 对于传统的Web应用，可以使用服务器端HTTP Session；对于Web服务类应用，不使用HTTP Session，基于无状态服务器模型做开发。
11. 自身包括了对于Web MVC的支持，熟悉Web MVC框架的开发者很容易理解。还内建了参数映射、参数验证等等传统Web MVC框架所支持的功能。
12. 内建了自己特有的导航对象栈的概念，对于支持传统的Web应用的开发（基于浏览器的导航）非常有帮助。
13. 提供了JSP标签库，对于传统的基于HTML表单的Web开发非常有帮助。
14. 支持与SiteMesh相配合，由SiteMesh来支持页面布局的重用。
15. 内建有与Spring的集成，集成起来非常容易。
16. 配置文件完全基于标准的web.xml，不需要额外的配置文件。大量使用默认配置，一般情况下足以满足常见的需求。
17. 拥有很好的文档。
18. 有内建的国际化支持。
    缺点：
19. 没有内建的HTTP认证机制，需要自行开发安全机制。
20. 对于内容协商的支持比较弱，仅支持HTML和XML格式的表现。需要加以扩展才能支持其他格式的表现。
    相关资源：
    教程：https://cetia4.dev.java.net/files/documents/5545/38989/cetia4_tutorial.pdf
    Axis2，最新版本1.2
    特点：同时支持SOAP和REST风格的Web Service。
    缺点：
21. 仅仅支持GET与POST方法。
22. 仅仅是以REST风格暴露出Web服务，数据格式仍然是包含SOAP封装的XML，不能使用更加有效的格式。
23. 只支持同步的调用方式。
24. 仅仅提供了以SOAP方式暴露Web服务的最小化的支持，不支持全面的REST架构设计。
    相关资源：
    简介：http://ws.apache.org/axis2/1_2/rest-ws.html
    sqlREST，最新版本0.3.1
    特点：
25. 为任何可以通过JDBC访问的数据库提供Web服务访问接口，自动将REST风格的HTTP请求转换为相应的数据库SQL语句，并将数据库中的记录编码为XML格式传给客户端。是REST风格的HTTP请求到数据库中的数据的直接映射。
26. 基于Servlet API开发。
    缺点：
27. 因为是REST风格的HTTP请求到SQL语句的直接映射，因此强制使用以SQL和关系数据库为中心的数据建模设计方法，不支持面向对象的设计。灵活性很低，难以实现较为复杂的业务逻辑。
28. 因为资源的定义仅限于数据库的表，难以实现更高层次的抽象，必然会导致非常细粒度的API。应用的性能和可伸缩性都难以保证。
    相关资源：
    教程：http://sqlrest.sourceforge.net/5-minutes-guide.htm
    REST-art，最新版本0.2
    特点：一个旨在替换复杂的SOAP框架的REST框架，用来作为替代SOAP方便地发布Web服务的工具。不是基于Servlet API开发。
    缺点：
29. 目前尚处于刚刚起步的阶段，功能非常少。
30. 不是基于Servlet API，带来了额外的学习成本。
    相关资源：
    教程：http://sourceforge.net/docman/index.php?group_id=175132

3、相关代码：
从网上下载了几个开源框架，最后决定使用sqlrest-1.0.zip ，在sqlrest基础上进行了点小改造