作者：韩陆
出版社：机械工业出版社
格式: AZW3, DOCX, EPUB, MOBI, PDF, TXT
Java RESTful Web Service实战试读：
前言
从我启动本书到完稿，历时一年有余。
此间，Java EE 7得到了更多服务器软件的支持，Jersey升级了9个小版本——我在动笔开始文字和示例代码编写的时候，Jersey刚刚推出2.0版本，到本书完毕时，版本号是2.9，这也是本书的最终版本。此后新版本带来的改变只有通过本书提供的源代码来同步更新。
此间，我积极参与和关注着Jersey项目的动向，通过关注Jersey官方文档、Jersey在GitHub托管系统的源代码、Jersey的Jira缺陷管理系统、Jersey的StackOverflow问答系统，对其修复缺陷、引入新功能和如何使用Jersey等事宜不断跟进。
我之所以这么做，目的只有一个，即希望为读者呈现的是一本Java领域REST开发的好书。为什么要写这本书
REST式的Web服务有多流行，相信每一位翻阅本书的读者都很清楚，冒昧地猜测，你可能想要看到的是一本讲述如何使用Java语言和Java EE平台，来实现这一风格的服务或者应用的书。这也正是我这两年来努力写作的初心和原动力。我相信，读者希望看到的内容不单单是追逐流行、风靡一时的“快餐”。作为开发者，我知道拥有对新技术、新标准的敏锐嗅觉非常重要，但我认为更难能可贵的是把一个业内认可的标准学好和用好。Java EE 7中包含了JAX-RS 2.0标准，是Java领域REST式的Web服务的规范；GlassFish是Java EE 7的参考实现项目集，Jersey是其子项目，是JAX-RS 2.0的参考实现。本书的目的就是要把JAX-RS 2.0说清楚，把如何用Jersey写好REST式的服务讲明白。本书特色
·第一本完整讲述使用Java标准规范实现REST的书籍。
·第一本完整讲述以JAX-RS 2.0参考实现实践Jersey的书籍。
·给出深度学习和实践JAX-RS的线路图和解决方案。读者对象
本书从实践角度，完整地诠释了JAX-RS 2.0（JSR 339），即Jersey 2.0的核心元素和REST开发过程。面向所有在Java领域学习和使用REST的读者。同样欢迎REST领域的其他语言的使用者通过本书了解REST的实现。
·技术路线：架构师、技术主管、研发工程师、REST小白（网络用语，本书指新手）；
·管理路线：部门经理、项目经理、产品经理；
·敏捷实践者。如何阅读本书
本书收纳了笔者近三年的RESTful实战经验，将REST理论与Java实现相结合，循序渐进地将使用Java开发REST式的Web服务中遇到的知识点和经验呈现给读者。每个章节中的知识点都精心设计了相应的示例代码，便于读者更好地理解和更及时地进行实践。从第11章开始，笔者从敏捷角度为读者呈现了一个完整和相对复杂的REST式的Web服务实例，相信这个实例能让读者更好地理解相关内容，同时，可以对敏捷开发和自动化测试有新的认识。
全书分为3篇，共11章。
第一篇共5章（第1~5章），讲述REST的基本理论和Jersey的基本实践。完成第一篇的阅读和示例代码的实践，读者可以学会使用Java开发REST式的Web服务的基本能力。
第1章 分别阐述了REST、REST式的Web服务、JAX-RS 2.0和Jersey 2.x的基本情况。
第2章 讲述了使用Jersey 2.x开发一个基于JAX-RS 2.0标准的应用的基本知识以及如何使用Jersey来集成Spring和JPA以快速开发一个REST式的Web服务。本章包含10个示例项目。
第3章 深入阐述了如何使用Jersey设计和实现REST式的Web服务的API。本章包含5个示例项目。
第4章 深入阐述了Jersey的Providers对REST请求的处理。
第5章 讲述了Jersey的客户端开发的基本实践和常用配置。
第二篇共5章（第6~10章），讲述写好REST程序的必要知识点。完成第二篇的阅读和实践，读者可以全面了解如何写好一个完整的REST式的Web服务。
第6章 全面讲述了如何实现一个安全的REST式的Web服务。
第7章 讲述了Jersey的测试框架及其使用。
第8章 讲述了Jersey对HTML5的SSE的支持和异步请求处理。
第9章 讲述了Jersey 1.x迁移到Jersey 2.x的要素和经验分享。
第10章 分享了REST式的Web服务的性能调优的经验。
第三篇包含1章（第11章），分享了5年外企工作中，我对自动化测试和敏捷的体会。完成本部分内容的阅读和实践，读者可以更宏观地审视REST的应用场景，起到抛砖引玉的作用。
第11章 讲述一个完整的REST项目的全过程。
全文由三个小版组成：“阅读指南”、“小白讲堂”（为某些在知识点上比较“小白”的同学介绍概念性的知识）和“宅人坑事”（技术宅最自豪和最担惊受怕的就是“踩坑”），旨在和读者分享基础知识和心得体会，只为交流，切勿对号入座。
第一篇推荐研发工程师和REST小白完整阅读，这部分包含了了解和使用JAX-RS 2.0完成学习和工作的必要章节。对于有基础的技术人员，可以作为实践的参考有选择地阅读。
第二篇推荐致力于提高自己的技术人员完整阅读，这部分包含了JAX-RS 2.0的高级功能。永不满足和持续学习的精神，会让你在关键时刻成为“关键先生”。架构师和项目经理在考虑安全、性能等问题时，可以参考相关章节。
第三篇推荐渴望实战指导的技术人员阅读和跟随实践。同时，该篇结合了笔者参与敏捷实践的体会，以scrum的方式进行开发管理。因此，敏捷实践者和相关的部门经理可以参考。
产品经理可以阅读与REST特性相关的章节，这样可帮你在设计应用方面有所提高。源代码勘误和交流
作为开发者，非常欢迎读者能与我一起交流JAX-RS 2.0相关的技术。我的邮箱是：feuyeux@gmail.com，新浪微博是：六爷1_1。
本书的勘误统计在https://github.com/feuyeux/jax-rs2-guide/wiki中，欢迎读者批评指正。致谢
感谢我的夫人Caroline。写作期间，没有时间陪你共度周末，甚至没有精力陪你共度以2开头的最后一个生日，也没有营造任何浪漫的气氛。我们的女儿从蹒跚学步到会唱儿歌，我没有更多的时间陪伴你们，而你一如既往地支持我，在此我对你表示深深的感谢。
感谢华章公司的杨福川。我最难忘的是最初谈到要出本书时与君一拍即合的快意，这为我此后动笔增添了无穷的动力和信心。同时，阁下给予我的信任和鼓励也极大地推动了本书的顺利完成。在此后一年多的交往中，我深深感受到了业内对杨福川专业水准的评价和他敬业的态度。
感谢华章公司编辑高婧雅专业和耐心的审阅和指正。我曾一度被这位可敬的东北妹子的严谨和勤奋打击，心生愧对华章精品精神的挫败感。但随着婧雅的不断鼓励和支持，我一遍遍改进着稿件，自信心得到了恢复，同时，内心得到了安慰，我没有偏离初心和那份原动力。非常感谢华章公司和婧雅。
感谢RedHat公司姜宁师兄的技术校对，感谢阿里巴巴公司许晓斌的敏捷校对。
最后，我要感谢Technicolor敏捷团队中的每一位成员，正是与各位度过的每一天，才让我有资本和信心与广大读者分享在REST式的开发中的经验和教训，并在本书中介绍自动化测试和敏捷实践的相关知识。第一篇 够用就好——JAX-RS 2.0基础■ 第1章 JAX-RS 2.0入门■ 第2章 JAX-RS 2.0快速实现■ 第3章 REST API设计■ 第4章 REST请求处理■ 第5章 REST客户端第1章 JAX-RS 2.0入门
本章逐一介绍以下4个概念：REST、REST式的Web服务、JAX-RS标准和Jersey项目。首先简要介绍一下这4个概念之间的联系：REST是一种跨平台、跨语言的架构风格，REST式的Web服务是对REST在Web领域的实现；JAX-RS标准是在Java领域，对REST式的Web服务制定的实现标准，Jersey是JAX-RS标准的参考实现，是Java EE参考实现项目GlassFish的成员项目。1.1 解读REST
REST（Representational State Transfer，表述性状态转移），源于REST之父Roy Thomas Fielding博士在2000年就读加州大学欧文分校期间发表的一篇学术论文——《Architectural Styles and the [1]Design of Network-based Software Architectures》 。论文中提出了REST的6个特点，分别是：客户端-服务器的、无状态的、可缓存的、统一接口、分层系统和按需编码。在此不敢“班门弄斧”，希望读者阅读一下这部开山之作，以此理解REST产生的原因和特点。
REST具有跨平台、跨语言的优势。从其诞生开始，广泛地得到了诸多语言的快速支持，比较著名的是ROR（Ruby on Rails）。ROR非常强调规约大于配置的理念，这一理念被诸多框架和工具支持——包括以Python领域的Django、Groovy领域的Grails为代表的框架，以及Maven、Gradle为代表的构建工具等，但REST本身只规定了面向资源，并没有包含如何定义和约束一个资源的标准。因此要提示读者，很多实现了REST的框架和工具所具备的特质，其全部特征未必都是REST定义的，包括本书要讲的JAX-RS标准的定义和Jersey等JAX-RS的实现。
REST在众多平台和语言上的支持，不仅包括上述列举的传统编程语言、脚本语言，还包括Node.js这样新兴的服务器端脚本语言。REST的无状态，代理友好性等优势，使对其支持的实现更加方便和简洁。阅读指南 至于为什么REST的出现影响了今天的互联网，以及Web的发展历程，可参阅附录中的Web简史。1.1.1 一种架构风格
REST是一种架构风格。在REST架构风格中，对象被抽象为一种资源（resource），资源的命名使用概念清晰的名词来定义。表述性状态是对资源数据在某个瞬间状态的快照，资源的某个瞬时状态被定义为一种表述（representation），这种描述性的状态包括资源数据的内容、表述格式（比如XML、JSON、Atom）等信息，一种资源可以对应多种表述。REST的资源是可寻址的，通过HTTP协议（RFC 2616）定义的通用动词方法（比如GET、PUT、DELETE、POST），并使用URI协议（RFC 3305）来唯一标识某个资源公布出来的接口。请求一个资源的过程可以理解为，访问一个具有指定性和描述性的URI，经由HTTP，将资源的表述从服务器转移到客户端，或者相反方向。
REST不是一种技术（technology），也不是一个标准（standard）[2]或协议（protocol），它使用既有标准：HTTP+URI+XML ，来实现其要求的架构风格。因此，与之对应的不是SOAP，而是像RPC这样的架构风格。1.1.2 基本实现形式
HTTP+URI+XML是REST的基本实现形式，但不是唯一的实现形式。REST从推出时就使用已有的HTTP协议、URI协议来描述，而对如何使用一种编程语言来实现，并没有进行任何描述和规定，甚至对于REST应该包含哪些传输类型或者数据格式也没有描述，但通常的实现至少包含XML格式。具体而言，HTTP协议和URI用于统一接口和定位资源，文本、二进制流、XML和JSON等格式用来作为资源的表述。正如采用已有技术XMLHttpRequest+JavaScript+XML（XML后来几乎被JSON替代）实现AJAX一样，使用HTTP+URI+XML实现REST的好处是让开发者持有这些已知的技术来开发REST，入门门槛较低，关注点更容易放到REST的核心概念和业务逻辑上。
这里要提示读者的是，以HTTP+URI+XML实现的应用并不一定是REST式的，但对于AJAX，这个逆命题（以XMLHttpRequest+JavaScript+XML实现的应用一定是AJAX应用）是成立的。因为AJAX是一种“技术流派”，而REST是一种架构风格。学习和使用REST的关键是掌握这种思想，而不是具体的实现形式。[1] 该论文的中文版译于2007年，中文名为《架构风格与基于网络的软件架构设计》，此后再次修订，名为《架构风格与基于网络应用软件的架构设计（中文修订版）》，详见本书的参考资料。[2] XML似乎成为了数据格式的借指，不仅代表XML本身。1.2 解读REST服务
英文RESTful对应的中文是REST式的。RESTful的应用或者Web服务是常见的两种REST式的项目部署、存在的方式。本节将介绍RESTful Web Services并对比和传统Web Services的不同。1.REST式的Web服务
RESTful Web Services（REST式的Web服务）是一种遵守REST式风格的Web服务。REST式的Web服务是一种ROA（Resource-Oriented Architecture，面向资源的架构）的应用。其主要特点是方法信息存在于HTTP的方法中（比如GET、PUT），作用域存在于URI中。例如，在一个获取设备资源列表的GET请求中，方法信息是GET，作用域信息是URI中包含的对设备资源的过滤、分页和排序等条件。2.对比RPC风格
相比Web服务领域广为流行的RPC（Remote Procedure Call，远程过程调用）风格，REST风格更轻量和快速。从方法信息角度看，REST采用标准的HTTP方法，而RPC请求都是HTTP协议的POST方法，其方法信息包含在SOAP协议包或HTTP协议包中，方法名称不具有通用性。从作用域角度看，REST采用URI显式定义作用域，而RPC的这一信息同样包含于协议包中，不能直观呈现。
RPC风格的开发关注于服务器-客户端之间的方法调用，而不关注基于哪个网络层的哪种协议。也就是说，RPC是面向方法调用过程的，相比而言，REST是面向资源状态的。RPC风格的两个代表是XML-RPC和大Web服务。（1）XML-RPC
XML-RPC是一种使用XML格式封装方法调用，并使用HTTP协议作为传送机制的RPC风格的实现。XML-RPC的请求方法都是HTTP协议的POST方法，请求和响应的数据格式均为XML。
XML-RPC的数据格式和使用XML作为资源的表述的REST外观上很相似，但数据的内容则大相径庭。REST式的XML信息的主体是对一个资源状态的表述，无须包含方法信息，因为其请求的HTTP方法就已经决定了这一点。XML-RPC的请求数据结构额外包含方法调用信息和参数信息。
对于响应信息的内容，两者也截然不同，REST式的通常会包含响应实体信息以及HTTP状态码和可选的异常信息，而XML-RPC的返回信息仅仅是对方法调用的响应信息。
XML-RPC是一种遗留技术，已经被SOAP取代。在Java领域，JAX-RPC标准已经被JAX-WS取代。XML-RPC的应用依然存在，著名的测试用例管理系统TestLink的对外接口就是使用PHP开发的XML-RPC。（2）大Web服务
大Web服务（Big Web Services）是Leonard Richardson和Sam Ruby在其所著的《RESTful Web Services》一书中，对基于SOAP+WSDL+UDDI+WS-标准栈等技术实现RPC风格的大型Web服务的统称。事实上，“大Web服务”这一说法也被Java EE 7的布道者在多次演讲中使用。在Java领域，对应的标准主要是JAX-WS 2.0/2.1/2.2（JSR 224）。相较REST式的Web服务，大Web服务功能更强大、设计更复杂。大Web服务同样是跨平台、跨语言的，对复杂的数据类型的支持也非常好。大Web服务是基于RPC风格的重量级的设计，因此方法和作用域无法通过直观断定，需要定义在消息中，而且方法名不是统一和通用的。同时，大Web服务走HTTP协议时，请求都是基于POST方法的。
对比RPC风格的Web服务，REST式的Web服务形式更简单、设计更轻量、实现更快捷。REST无须引入SOAP消息传输层，无须注册服务，也没有客户端stub的概念等。但是，REST风格的Web服务并没有像大Web服务那样提供诸如安全策略等全面的标准规范。
大Web服务和REST式的Web服务各有其优势，并不是一种代换关系。在实际开发中，两者共存于一个项目中也是一种解决方案。3.对比MVC风格
MVC风格的出现将模型、视图、控制解耦，其亮点是从前到后的一致性，其结构简洁、逻辑清晰，易于扩展和增强。MVC在Java领域的普遍实现方式是在Web前端使用标签库来对应服务端的模型类实例和控制类实例，标签库和服务端依赖库可以是松散的耦合——比如Spring生态系统，也可以是全栈式的统一体系，比如JSF体系。但无论如何实现，在Web前端的开发过程中，必须时刻考虑页面标签和服务端的映射关系，包括模型类的匹配和转换，数据结构，控制类输入和输出的参数类型和数量等。
因此，MVC风格偏重于解决服务器端的逻辑分层，客户端是逻辑分层的延伸。MVC的标签库，虽然其形态已经和HTML页面融合，但本质上还是Java编写的装饰模式的类实例，对应的是服务器端使用Java编写的模型类或者控制器类，因此MVC很难实现跨语言解耦。而REST风格偏重于统一接口，因此具体实现就可以跨平台和跨语言。正如附录中Web简史中所述，REST推动了Web开发的新时代，使用纯HTML作为客户端，没有服务器端和客户端的耦合。显而易见，使用纯HTML开发的REST客户端和使用Java开发的REST服务器端并不存在语言上的耦合。
MVC和REST式并不是互斥的，像Spring的MVC模块已经支持REST式的开发。Jersey作为JAX-RS标准的实现，也实现了MVC的功能，可参考相关模块：jersey-mvc、jersey-mvc-freemarker和jersey-mvc-jsp。需要说明的是，本书致力于讲述JAX-RS，对Jersey实现中的JAX-RS之外的功能只做必要的讲述。由于MVC和REST之间有更多的并行存在性，因此本书余文没有将MVC放入讲述之列。1.3 解读JAX-RS
JAX-RS是Java领域的REST式的Web服务的标准规范。如果我们只学习工具的使用而不知标准是怎样定义的，那么可能不会理解其本质。因此，我们首先来学习和掌握JAX-RS规范，这是使用Java完成REST式的Web服务的基础和前提。1.JAX-RS2标准
Java领域中的Web Services是指实现SOAP协议的JAX-WS。直到Java EE 6（发布于2008年9月）通过JCP（Java Community Process）组织定义的JSR 311（http://www.jcp.org/en/jsr/detail?id=311），才将REST在Java领域标准化。JSR 311名为The Java API for RESTful Web Services，即JAX-RS，其参考实现是GlassFish项目中的Jersey 1.0。此后，JSR 311进行了一次升级（2009年9月），即JAX-RS 1.1。JAX-RS诞生后，时隔5年（2013年5月）发布的Java EE 7包含了JSR 339，将JAX-RS升级到JAX-RS 2.0（http://www.jcp.org/en/jsr/detail?id=339）。JAX-RS 2.0在前面版本的基础上增加了很多实用性的功能，比如对REST客户端API的定义、异步REST等，对REST的支持更加完善。
JAX-RS的版本对应的参考实现的Jersey项目版本信息参见表1-1。表1-1 JAX-RS标准和Jersey版本信息2.JAX-RS 2.0的目标
JAX-RS 2.0标准（即JSR 339）中定义了目标、非目标和元素等内容。JSR 339标准中的这部分内容通常被以实现业务功能为目的的开发人员所忽视，在此和读者分享的一个开发经验是，要掌握一项技术，要先掌握它背后标准的定义。我们首先来看看JAX-RS 2.0的目标。
1）基于POJO：JAX-RS 2.0的API提供一组注解（annotation）和相关的接口、类，并定义了POJO（Plain Ordinary Java Objects）对象的生命周期和作用域。规定使用POJO来公布Web资源。
2）以HTTP为中心：JAX-RS 2.0采用HTTP协议，并提供清晰的HTTP和统一资源定位（URI）元素来映射相关的API类和注解。JAX-RS 2.0的API不但支持通用的HTTP使用模式，还对WebDAV和Atom等扩展协议提供灵活的支持。
3）格式独立性：JAX-RS 2.0对传输数据（HTTP Entity）的类型/格式的支持非常宽泛，允许在标准风格之上使用额外的数据类型。
4）容器独立性：JAX-RS 2.0的应用可以部署在各种Servlet容器中，比如Tomcat/Jetty，也可以部署在支持JAX-WS的容器中，比如GlassFish。
5）内置于Java EE：JAX-RS 2.0是Java EE规范的一部分，它定义了在一个Java EE容器内的Web资源类的内部，如何使用Java EE的功能和组件。小白讲堂
WebDAV（Web-based Distributed Authoring and Versioning，基于Web的分布式创作和版本控制）是IETF组织的RFC 2518协议。WebDAV基于并扩展了HTTP 1.1，在HTTP标准方法以外添加了：
·Mkcol：创建集合；
·PropFind/PropPatch：针对资源和集合检索和设置属性；
·Copy/Move：管理命名空间上下文中的集合和资源；
·Lock/Unlock：改写保护，支持文件的版本控制。
针对在REST风格的Web服务中是否应该使用WebDAV，业内的声音并不一致，持反对意见的人的主要观点是WebDAV带来了非统一的接口，这违背了REST的初衷。本书的示例将不采用WebDAV，但文字部分将讲述如何支持WebDAV。Atom类型传输格式将在3.3节讲述。3.非JAX-RS 2.0的目标
那么哪些不是JAX-RS 2.0的目标呢？
1）对J2SE 6.0之前版本的支持：JAX-RS 2.0中大量使用了注解（annotation），需要J2SE 6.0以及更新的版本，因此不提供对J2SE 6.0以下版本的支持。
2）对服务的描述、注册和探测：JAX-RS 2.0没有定义也无须支持任何服务的描述（description）、服务的注册（registration）和服务的探测（discovery）。
3）HTTP协议栈：JAX-RS 2.0没有定义新的HTTP协议栈。承载JAX-RS 2.0应用的容器提供对HTTP的支持。
4）数据类型/格式类：JAX-RS 2.0没有定义处理实体内容的类，它将这一类型的类交由使用JAX-RS 2.0的应用中的类去实现。4.解读JAX-RS元素
最后，我们来看看JAX-RS 2.0中定义了哪些元素。
1）资源类：使用JAX-RS注解来实现相关Web资源的Java类。如果用MVC的三层结构来解读，那么资源类位于最前端，用于接收请求和返回响应。通常但不是约定使用resource作为包名，三层的包定义形如：resource-service-dao。
2）根资源类：使用@Path注解，提供资源类树的根资源及其子资源的访问。资源类分为根资源类和子资源类。由于Jersey默认提供WADL（参见2.4节），因此每个应用公布的全部资源接口可以通过WADL页面查阅。
3）请求方法标识符：使用运行期注解@HttpMethod，用来标识处理资源的HTTP请求方法。该方法将被资源类的相应方法处理，标准的方法包括DELETE、GET、HEAD、OPTIONS、POST、PUT，详见3.1节。
4）资源方法：资源类中定义的方法，使用了请求方法标识符，用来处理相关资源的请求。就是上面提到的资源类的相应方法。
5）子资源标识符：资源类中定义的方法，用来定位相关资源的子资源。
6）子资源方法：资源类中定义的方法，用来处理相关资源的子资源的请求。
7）Providers：一种JAX-RS扩展接口的实现类，扩展了JAX-RS运行期的能力。第4章详述了各种Providers及其实现。
8）Filter：一种用于过滤请求和响应的Provider，详见4.4节。
9）Entity Interceptor：一种用于处理拦截消息读写的Provider。
10）Invocation：一种用于配置发布HTTP请求的客户端API对象，详见5.1.3节。
11）WebTarget：一种使用URI标识的Invocation容器对象，详见5.1节。
12）Link：一种携带元数据的URI，包括媒体类型、关系和标题等，详见3.4节。1.4 Jersey项目概要
Jersey是JAX-RS标准的参考实现，是Java领域中开发REST式的Web服务的“正统”工具。这样讲述的目的是避免读者混淆REST领域诸多工具的地位，并无偏好推荐之意。本节将带领读者走进Jersey的世界。
Jersey项目是GlassFish项目的一个子项目，专门用来实现JAX-RS（JSR 311和JSR 339）标准，并提供了扩展特性。1.获得Jersey
Jersey项目的网址是https://jersey.java.net，这是Jersey的官方网站。该网站同时提供了JAX-RS和JAX-RS 2.0两个并行版本，分别是Jersey 1.1（截至本书发稿，最新版本是Jersey 1.18）和Jersey 2.0（截至本书发稿，最新版本是Jersey 2.9）。读者可以通过单击“latest Jersey User Guide”获取和阅读最新版本的用户手册，这是官方发布的第一手的参考资料。
Jersey项目的下载地址https://jersey.java.net/download.html，Jersey项目使用Maven管理项目，该页面至上而下分别是：
·JAX-RS标准列表链接。
·Jersey最新参考实现的jar包下载。
·Jersey最新参考实现的示例代码下载。
·创建基于Maven管理的JAX-RS容器Jersey应用。
·创建基于Maven管理的Servlet容器Jersey应用。
·JAX-RS 1.1的参考实现包下载。2.Jersey源代码
Jersey 2使用GitHub管理源代码，GitHub的客户端非常简洁。单击首页下方的“Source Control”进入https://jersey.java.net/scm.html页面，该页面提供了如何使用GIT来克隆Jersey的源代码的介绍。Jersey源代码的托管地址是https://github.com/jersey/jersey（见图1-1）。
如图1-1所示，Jersey项目的源代码是使用Maven构建的多模块项目。每个目录代表一个模块，比如core-server目录就是Jersey的Server模块。bom目录是个特殊的目录，是Maven的元数据目录，用于多模块Maven项目的组织和定义。通过浏览该页面可以观察到Jersey框架的模块，本章随后会介绍Jersey的各个模块。第2章将对基于Maven管理的Jersey应用做详细的讲述和演示。图1-1 Jersey源代码仓库小白讲堂
Maven（http://maven.apache.org/）是Apache开源组织的项目，该项目用于构建和组织Java的项目。读者如果对Maven不熟悉，推荐阅读许晓斌（Juven Xu）所著的《Maven实战》（机械工业出版社出版）。
如果读者对命令行不熟悉或者没有兴趣，可以使用GUI工具来完成源代码的管理。对于托管在GitHub的项目，可以使用GitHub官方提供的客户端来管理源代码，Windows版本下载地址：http://windows.github.com，Mac版本下载地址：http://mac.github.com。这款工具的使用非常简单，如图1-2所示，左侧树包括本地仓库和GitHub远程仓库两个结点。右侧是仓库列表，示意图中包括本书的示例项目jax-rs2-guide、第11章示例项目jax-rs2-atup和Jersey源代码等仓库。需要指出的是，其处理版本冲突的能力不足，需要借助命令行来完成。小白讲堂
GIT是一种开源的分布式SCM（Source Code Management，源代码管理）工具，下载地址为http://git-scm.com/download。读者如果对GIT不熟悉，推荐阅读蒋鑫所著的《Git权威指南》（机械工业出版社出版）。
GitHub是GIT服务器中比较知名和成功的，它提供了基于身份认证的项目托管等功能。时下非常多的知名开源软件都将版本控制迁移到GIT并使用GitHub托管。如果可以，希望读者能从https://help.github.com/中得到更多信息。图1-2 GitHub客户端示意图3.Jersey问答
StackOverflow是专业的程序员问答系统，Jersey提供了其问题列表地址：http://stackoverflow.com/questions/tagged/jersey。从中可以看出开源社区对问答系统的重视。另外，邮件列表也是一种知识共享的途径，读者可以自行订阅，地址是：https://jersey.java.net/mailing.html。[1]
实践趣事 这里想和读者分享的是，一名不断成长的程序员 一定是勤奋和富有热情的，这是开源社区和StackOverflow这样的问答系统的生存基石。社区和个人的成长是相辅相成的。推荐读者在遇到问题时，第一个想到的是搜Google、搜StackOverflow，而不是张嘴就问，问周边的人应该是正确做法中最后的办法。顺便要说的是，英语是程序员绕不开的技能，一起加油吧！4.Jersey项目管理
Jersey使用JIRA作为项目管理平台，地址是https://java.net/jira/browse/JERSEY。JIRA和StackOverflow不同的是，这个平台是Jersey团队日常开发的管理平台，也就是说，这是Jersey官方的缺陷管理平台，用于上报缺陷和改进意见，而不是社区性质的交流平台。我们可以从中了解到Jersey项目的进展情况。Jersey是一个非常活跃的项目，不仅可以从GitHub的源代码的提交活动中看到该项目频繁的更新，在JIRA中，也可以看到该项目推进的速度。宅人坑事
这里为喜欢开源社区活动的读者举个例子。我在撰写本书的开始，Jersey 2.0并不支持与Spring的集成，因为Jersey的IoC容器由GlassFish的另一个子项目HK2来支持。随后，我在JIRA上发现一个Jersey 2.x支持与Spring集成的任务被创建了（https://java.net/jira/browse/JERSEY-1957），此后我经常观察其进展状态，最终看到了这个功能在Jersey 2.2中以扩展包的形式发布了。因此，当使用Jersey时，如果遇到Jersey本身的问题，可以跟踪Jersey的JIRA平台来查看Bug的修复状态，包括将在哪个版本修复，有什么样的临时解决办法（workaround）。同时，跟踪JIRA也可以了解新版本的发布情况，包括新增哪些功能，升级给哪一部分带来性能、安全的提升等。换句话说，JIRA展示了Jersey项目的缺陷修复和新功能发版的计划（roadmap）。5.Jersey许可
开发者使用开源软件的前提是了解它的许可证版本，否则可能会带来侵权问题。相信在正规的公司，大家都有被开发管理部门的人“恐吓”的经历。开发者需感谢开发管理部门所做的工作，他们为公司规避了商业侵权的风险，因为引用的源代码如果出自“传染性”许可，该项目是不能用于闭源的商业用途的。
Jersey的许可证说明地址是：https://jersey.java.net/license.html。从中我们可以了解到Jersey使用的是双许可证：CDDL（Common Development and Distribution License，开源通用开发和分发许可证）1.1和GPLv2（类路径例外）许可证。双重许可是依照两套（或更多套）不同的条款和条件分发相同软件的做法。在为软件授予双重许可时，接收人可以选择他们希望依照哪种条款获得软件。使用双重许可的两个常见动机是遵循商业模式和保持许可证兼容性。GPLv2.0许可证为无法依照CDDL许可证使用Jersey的供应商提供了一个额外选项。Jersey许可证使整套产品和包保持一致（GlassFish项目同样依照CDDL和GPLv2（类路径例外）授予双重许可）。6.Jersey的模块
Jersey框架是由核心模块、容器模块、连接器模块、Media模块、扩展模块、测试框架模块和GlassFish Bundle模块7个大的模块组成。这不是一成不变的，随着Jersey的不断发展和完善，会有新的模块加入进来。推荐读者浏览官方文档，最新版本的地址为：https://jersey.java.net/documentation/latest/modules-and-dependencies.html，从而获得最新的信息。小白讲堂
类路径例外是由自由软件基金会的GNU/类路径项目制定的。它允许用户将依照任何许可证提供的应用程序链接到依照GPLv2许可的软件中包含的库，而该应用程序不受GPL要求公开其本身的限制。为什么需要使用类路径例外？因为作为“基于[GPL]程序的作品”的一部分提供的所有代码还应获得GPL许可。因此，需要指定GPL许可证例外情况，以便明确将链接到GPL实现的任何应用程序从该许可要求中排除。类路径例外实现了这一目的。（1）核心模块
Jersey核心模块由通用包、服务器实现和客户端实现3个子模块组成，是使用Jersey必需的依赖，见表1-2。表1-2 Jersey核心模块列表（2）容器模块
Jersey提供了3种对应于外部容器的HTTP容器，分别是Grizzly 2、JDK-HTTP和SIMPLE-HTTP，Grizzly 2同时提供了Servlet容器。对于Servlet的实现，Jersey提供了对Servlet 2.x和Servlet 3.x两个版本的实现。它们对应的包名见表1-3，详情可参考第2章。表1-3 Jersey容器模块列表（3）连接器模块
Jersey客户端底层依赖连接器实现网络通信，如果标准的客户端模块无法实现功能需求，可以考虑引入Grizzly连接器或者Apache连接器，见表1-4，详情可参考第5章。表1-4 Jersey连接器模块列表（4）Media模块
Jersey Media模块是支持Jersey处理传输数据媒体类型的模块。该模块提供了4种处理JSON的方式，分别是Jackson、Jettison、MOXy和JSON-P。另外，Multipart包用于对Form表单的支持，SSE用于对Server Sent Events支持，见表1-5，详情可参考第3章。（5）扩展模块
Jersey生态环境中包含了许多JAX-RS 2.0标准之外的功能，比如MVC、Bean验证等辅助REST实现的模块，还有像Spring支持包这样的对第三方框架支持的模块见表1-6。表1-5 Jersey Media模块列表表1-6 Jersey扩展模块列表（6）测试框架模块
Jersey提供了非常易用且功能强大的测试框架，见表1-7。测试框架提供了测试过程中完整的服务器端和客户端功能，通过测试框架，开发者可以减少很多模板代码的编写。详情可参考7.1节。表1-7 Jersey测试框架模块列表（7）GlassFish Bundle模块
GlassFish Bundle模块是Jersey提供的用于以Bundle方式支持GlassFish服务器的模块，包括CDI和EJB集成的扩展包，见表1-8。表1-8 GlassFish Bundle模块列表宅人坑事
Jersey在2.6版本做了一次包重构，清除了对Guava和ASM的自然依赖。如果读者的项目需要做Jersey版本迁移，需要注意这一点。新的包名为：jersey.repackaged.com.google.common和
试读结束[说明：试读内容隐藏了图片]