logo资料库

RESTLET框架学习书籍.pdf

发布时间：2022-05-30 发布人：admin 分类：说明书 资料大小：2.57M 资料格式：pdf 举报 版权申诉
第1页 / 共120页
第2页 / 共120页
第3页 / 共120页
第4页 / 共120页
第5页 / 共120页
第6页 / 共120页
第7页 / 共120页
第8页 / 共120页
资料共120页，剩余部分请下载后查看
    Restlet in Action 目录: 第一部分：Getting started 1. 反思 web 开发 2. 设计一个 RESTful web API 3. 开始一个 Restlet 应用 4. 在本地部署一个 Restlet 应用 第二部分：Getting ready to roll out 5. 设计和使用 Restlet representations 6. Restlet 应用安全 7. RESTful web API 文档和版本 8. Restlet 应用提高 第三部分：Further usage possibilities 9. 在云端部署一个 Restlet 应用 10. Restlet 在浏览器端和移动端的使用 11. 拥抱语义网 12. 展望 附录： A． Restlet 安装 B． 测试工具 C． 参考列表 D． 其他帮助信息
    第一部分：Getting started Restlet 是 Java 开发者的开源 web 框架。它使你能够更加全面的使用 REST 这种原生的 web 架构。作为一个面向对象的框架，它提供了众多的类和示例供你调用和扩展，让你编写出更 好的代码，使你可以更加专注于自己的领域需求。它会以它的方式打开你通向 web 的每扇 门，从传统 web 到语义网，从 web 服务到富 web 客户端以及 web 站点，从移动 web 到云 计算。 Restlet 框架以一种简单而统一的方式支持所有这些形式的 web。你可以使用它发布或者 使用 web 页面和 web 服务这样的 web 资源。Restlet 的优点之一在于在客户端和服务器端支 持 HTTP 的所有特性，比如：条件方法，内容协商，content ranges,content compression,content verification。它带来的巨大变革在于你不再需要让自己的应用适应 web，而是可以很自然的 使用它的全部特性。 在第一章里，我们将带你开始了解 REST 和 Restlet 框架。秉承 Manning 的“实战”系列 的书籍，我们将快速深入技术核心以开发出你的第一个 Restlet 程序。在这之后，第二章将 通过指导你用 web 的理念设计 RESTful web API 帮助你以 REST 的方式思考和设计。这是唯一 不特定于 Restlet 的章节，但它为后面的学习提供了必要的建议和示例。 第三章将实现前面章节的设计，告诉你如何创建完整的 Restlet 应用。你将学习怎样整 合 Restlet 的基石比如 resources,filters 以及 routers。 作为 Restlet 框架的优势之一，是它有在各种技术环境下工作的能力，第四章将讲解怎 么样在你自己的电脑上本地部署 Restlet 应用，通过简单的 Java SE 虚拟机或者 Java EE 服务 器。 这涵盖了很多令人兴奋的内容，让我们现在就开始吧！ 1. 反思 web 开发 本章包含以下内容： *以一种统一的方式使用 web *介绍 REST 这种 web 的原生架构的基本架构元素 *测试 Restlet 这个基于 Java 的开源 REST 框架的 2.0 版本 一篇发表于 2000 年的博士论文是怎么样重塑我们对 web 的思考以及我们开发 web 服务的方式，不论是 web 客户端还是 web 站点？第一章将告诉你关于 REST 的故事以及关于 Restlet 技术的一些概述。 我们还将解释 REST 如何澄清 HTTP 协议的设计，并且帮助我从它的所有特性 中受益。REST 和 HTTP 之间的关系我们将会详细讨论，我们还将解释 REST 怎么 样取代 RPC。 在这之后，我们将用 Restlet 重写经典的”hello,world”，包含客户端和服务器端。 然后我们将尝试回答你可能怀有的关于 Restlet 的实际价值的疑问，展示它主要 的特性以及它的整体架构。 1.1 Supporting all web features with REST 数以亿记的人们以各种方式使用 web。数以百万的开发者创建着 web 应用。然而，仅仅 只有他们中的一小部分听说过 REST 这种基于 web 的原生架构。REST 由 Roy T.Fielding 创 造，他是 HTTP1.1 这一 web 基础协议的主要架构师。 REST 是 Representational State Transfer 的缩写。这是一系列的原则，当被正确的应用时， 可以帮助你在建立软件架构和应用时从所有的 web 特性中获益。这些特性众多并且包含 巨大的可扩展性，高效的网络利用以及客户端和服务器端的独立使用（松散耦合）。 现在你会在不了解哥特式艺术的情况下去建造哥特式教堂么？当然不会！这对 web 同
    样适用；你不可能在不了解 web 架构的情况下去建立 web 应用。通过理解 REST 定义的 一些原则并在开发环境中应用他们，你将可以创造拥有高度可扩展，松散耦合，性能和 简单的分布式系统。 在这一节，我们将为你展示 web 的蓝图，它是怎么样成为我们信息系统的中心并且怎 么样影响着各种类型的应用和平台，比如移动设备。接着，我们将展示 REST 以及它的 架构元素，解释它与 HTTP 协议的关系，最后将对它和 RPC 进行对比。 1.1.1 The all-embracing Web 所有人都知道传统 web。这是一种基于超文本以 web 浏览器和 web 服务器为主的 web。近来，AJAX 提供了一种从 web 页面上异步发送 HTTP 请求的方式，以及一种 富客户端应用的途径。这种新的使用 web 的方式已经产生了很多新的框架，比如 jQuery 或者 Google Web Toolkit，可以更加方便开发 web 的动态的，基于 JavaScript 的浏览器端应用。 我们的移动电话也变得更加智能，支持全方位的 web 访问。最近的潮流由 iPhone 和 Android 引领。在那些个人电脑不是很普及的国家，移动电话将成为访问 web 的 主要方式。 很显然的，要适应这些所有类型的 web 为设计 web 应用带来了挑战。他们将必须 可以适应各种环境，比如小的屏幕，可以迅速适应新的市场确实或者新的用户需求。 管理以上三种类型的 web 已经是个头痛的问题，但是如果出现下一代 web，比如 很多人谈论的语义网，那又会怎么样呢？。。。。。。 另外，云计算可以解决我们的可扩展的需求么？它承诺减少成本，让维护更简单并 且让组织者更加迅速的管理基础设施。将你的数据储存在 Amazon S3 上，不需要担 心备份和硬盘空间或者将你的 web 应用部署在 Google App Engine 上，利用其无线的 处理能力和网络带宽不是很好么？ 这些只是举些例子以说明 web 正变的无处不在并且对我们的信息系统产生巨大的 影响。在过去的十年里，我们都尝试着适应它，为 web 开发网关和通道，以及建立 各种类型的应用和服务。 我们相信是时候换种思路了：从 web 本身去建立应用和服务而不是不断适应它。 通过 REST 你将可以以一种统一而有效的方式去考虑 web。利用你手中的 Restlet，你
    将可以直接建立统一的 web 应用，同时获得支持所有这些类型 web 的能力。 在这一点上，我们有必要澄清我们对于 web 应用的定义。在我们的术语中，它包 含各种通过 HTTP 交互的 web services，静态和动态的 web 站点以及各种基于浏览器 的或者独立的 web 客户端。甚至，通常一个 web 应用可以混合这几种类型，比如在 作为一个 web service 的同时又是一个 web 客户端。 1.1.2 How REST explains the architecture elements of the Web Roy T.Fielding 是 web 的重要人物之一。从 1994 年到 2000 年之间，他在加里福利亚 大学攻读博士，期间他致力于规范许多 web 标准，贡献了很多合理的建议。 在 2000 年，他发表了一篇论文，标题为“Architectural Styles and the Design of Network-based Software Architectures”，其中有一章节为：“Representational State Transfer(REST)”。这个理论在一些年里仍然是个秘密，但是当 REST 逐渐推广和快速 传播，它成为了计算机科学史上被最广泛阅读的理论之一。 为什么要对这个如此抽象和难于理解的文章这么感兴趣呢？嗯，REST 很好的解释 了 web 的架构，它包含了所有 web 应用应当遵循的蓝图。 这个理论始于对软件架构的一般讨论，延续了基于网络的应用架构的特点。Fielding 那时建议对架构类型作分类比如 pipe 和 filter，client-server,layered systems,remote sessions,virtual machines,code on demand 或者 distributed objects。建筑家们也会对建 筑的风格有同样的讨论比如罗马式或者哥特式。 Fielding 将 软 件 架 构 描 述 为 架 构 元 素 的 配 置 ， 在 REST 里 表 示 为 ： components,connectors,resources,representations 以及其他的一些。在下面的章节， 我们看到这些高级别的架构元素，这为开始理解 REST 和 Restlet 提供了极佳的途径。 Resources 让我们从最重要的元素：resources 开始我们的探索。它们是 web 的基石。一个资源 可以是网络上一个应用通过网络暴露给其他应用使用的任何事物。它可以是一个银 行账户的余额，巴黎当前的温度等等。。。 这些资源的一个重要特征是它们是相互链接的，比如嵌入到 HTML 文档中的超链接 或者指向当前博客的 URI。整个 web 就是一个可以被快速定位和发现的分布式的资 源的集合。 令人惊奇的是这些被人类接受、更新以及删除的资源正在逐步演化和生长。我们用 图 1.3 说明了这一点，在图上我们还通过超链接展示了资源之间的关系。事实上， 他们也可能很少被组织在一起，有事甚至是断开的：我们都熟知的令人讨厌的 404 “Error not found”页面也为 web 的生动提供了证明。
    为了让用户从世界的任何位置获取到它们，每个 resource 被指定了一个唯一的名称， 更准确的说是一个统一资源定位符或者 URI（比如：“http://www.paris.fr/weather”）， 确保可识别并且可用过网络远程访问。 另外，如图 1.4 所示，一个 resource 可以通过 representations 暴露它的状态，其中 包含元数据（比如大小，媒体类型以及字符集）和真实内容（比如一个二进制影响 或者文本文档）。举例来说,eBay 上的交易确认的 representation 可以是一个 HTML 文 档，一张婚礼照片的 representation 可以是一个 JPEG 的二进制流，地址薄中的一个 联系人的 representation 可以是一个 XML 片段，等等。。。 让我们深入到 resource 的内部去看看它在一个信息系统中的典型实现。在下面图 1.5 中的大圆从与 resource 交互的外部环境中将其划定出来。 Resourece 由中间的那些状态描述组成，由任何可靠的方式管理并且由标准的方法 定义它的接口。
    HTTP 是在 web 中操作 resources 的主要协议。它是一个 client-server 式的网络协议： 一个客户端应用，可以是一个 web 浏览器或者其他类型的程序，发送一个请求到一 个服务器端应用，服务器端处理请求并返回一个响应。这个响应可以是一个典型 web 站点的 HTML 文档，一个典型的 web 服务的 XML 文档或者其他类型的数据。事实上 这些 representation 信息和 raw 数据以一种同样的方式被处理是尤其有趣的：它整合 了这两种在过去往往由完全不同的技术实现的分布式系统。 但是 HTTP 不仅仅定义一个请求或响应的消息交换样式：它更指定了在客户端和服 务器端交互的语义。通过 HTTP，你不需要说“发送这个请求到这个应用”或者“返 回这个响应”。事实上，一个请求指向一个特定的 resource，以 URI 进行识别，并且 通过由 HTTP 定义的 GET，PUT，POST 和 DELETE 方法进行操作。因此一个 HTTP 客户 端程序表达这些事物类似于“给我这个资源的当前状态的一个 representation”（通 过 GET），或者“利用我发送给你的 representation 创建或者更新一个 resource”（通 过 PUT），或者“删除这个资源”（通过 DELETE）等等。 为了让你们意识到 resource 的重要性，你们可以将它们比作面向对象体系中 objects。它们将是你的 web 应用的支柱，通过状态和行为暴露出来。与面向对象体 系相比，这些标准方法与面向对象方法类似，不过有一个关键的不同：它们有数量 上的限制而且其行为已经被 HTTP 等协议预定义。当应用使用这些预定义方法，代 替它们自己定义的，去表达网络上的交互，那些网络基础设施就在某种程度可以理 解，这些交互的语义。通过这些理解带来了一些提供很多关键服务比如缓存和自动 消息重发的能力。。。 然而，注意到 REST 自身并没有定义一个伪数据库，那些资源的状态只能通过 PUT 和 POST 方法提供。完全可以拥有一个只支持 GET 方法的只读资源。它的状态可以 由其它方式比如通过文件系统，一个关系型数据库物理传感器等提供甚至更新。现 在 已 经 存 在 基 于 RESTful 的 数 据 库 ， 比 如 Apache CouchDB （http://couchdb.apache.org/）。 另一个主要优点是统一接口的机制，它减少客户端和服务器端的耦合。举例来说， 事实上当你访问一个新的 web 站点的时候你不需要生成存根或者代理并且重新编译 你的 web 浏览器，这都得益于通过统一接口操作资源。在第 2 章，我们将对此进行 更深入的比较并且讨论 REST 介绍的面向资源体系。 Components 我们刚刚看到 resources 在 web 上无处不在，但是并没有更多的提到它们如何高效
    的被分配、管理以及被访问到。关于这个在 REST 中有一个 components 的概念，封 装了资源的状态和行为的粗粒度软件元素，它将资源暴露在类似 Internet 这样的分 布式网络上。 在下面的图 1.6 中，我们说明了分布在 web 上的四个 components。虚线对应于一 个网络通信，通常是基于 TCP/IP 之上的 HTTP 协议。 有很多类型的 components，比如用户代理，原始服务器，网关或者代理。最常见 的用户代理是 web 浏览器（比如 Mozilla Firefox）以及普通的原始服务器是 web 服务器和 web 引擎（比如 Microsoft IIS 和 Apache Tomcat）。。。 Connectors Components 之间显然需要相互通信。对此，它们使用图 1.7 所示的 connectors 去抽 象类似网络管理（比如 TCP/IP 包）和相关协议（比如 HTTP 连接）这样的通信细节。 在 REST 中，这些通信是无状态的。客户端自发的发送一个请求，服务器端返回一 个响应，然后通信就结束了。 有很多类型的 connectors，比如 client connectors，server connectors，caches，resolvers 以及 tunnels。最常见的 connectors 是 client connectors（比如 Apache HTTP Client library） 这样发送请求的以及 server connectors（比如 Jetty HTTP Server library）这样监听收 到的请求并返回响应的。Restlet 框架为多种协议（HTTP,POP3,SMTP,FILE 等等）提供 了很多 connectors。 Interaction Scenario 让我们考虑一个更完整的场景，如图 1.8 所示，当一个用户代理（比如 web 浏览器） 作为原始服务器的客户端，调用指定的以 URIs 标识的 resources 资源上的方法。通 常情况下第一个 GET 请求将以 HTML 文档的形式获取“Resource 1”的“Representation 1.1”。
    然后，根据 representation 中的超链接，用户代理将从同一个 resource 中获取到第二 个 representation，另外一种格式（比如 PDF 文档）的“Representation 1.2”。最后， 根据另外一个超链接，它可以访问到另外一个 resource“resource 2”并且获取到它 的 representation。当然，对一个用户代理和原始服务器之间仅仅是 GET 方法调用的 一系列交互来说是没有限制的。 1.1.3 Understanding the relationship between REST and HTTP 在介绍了一些 REST 的概念之后，你可能仍然不清楚 REST 和 HTTP 之间的关系。REST 肯定不同于 HTTP，因为它表示的不是同一类型的事物。REST 只是一个抽象，它定义 了一种架构类型。而另一方面 HTTP 是一个实际的通信协议。 除了这本质上的区别之外，REST 和 HTTP 是很好的朋友，因为 HTTP 体现了 REST 的原则。因此运用 HTTP 去创建 RESTful 的应用是很方便的。然而，运用 HTTP 或者 HTTP 工具使你的应用 RESTful 是不够的。就如同你可以使用面向对象的语言去创建 非面向对象的程序一样，你可以使用 HTTP 协议去创建非 RESTful 的应用。这本身未 必是坏事，但是如果你想让你的应用受益于 REST 架构风格的特征，你必须切实应用 REST 的原则。 最后，请注意 REST 不依赖于类似 HTTP 这样的指定的协议。它可以和其他协议高 效的使用。。。 REST as an alternative to RPC 自从 1991 年 web 诞生，在新世纪之初它得到了快速而深入的传播。。数十年来人们 已经开发了 web 站点，web 客户端以及 web 应用并且下一步就是开发机器对机器的 web services。 从七十年代起软件业就已经在开发分布式应用，在 80 和 90 年代，分布式系统的传 统架构之一就是 RPC（远程过程调用）以及分布式对象，它适用于由 CORBA（Common Object Request Broker Architecture）而流行的面向对象编程。渐渐地，RPC 架构对 web 的适应以“web services”的形式出现。它利用流行的 XML 语言去定义标准的 SOAP 消息信封，并且使用 HTTP 作为默认的传输协议。在图 1.9 中，你可以看出 RPC 怎么进化为 AMF（近来由 Adobe 为它们的 Flex RIA 平台定义的一个协议）那样的协 议，以及 REC 与 REST 之间的大致曲线。 1.1.4
    分享到：
    赞 收藏

    相关推荐

    资料库

    开发技术

    共收录19306份资料，累计14个分类，关注成员有19位，主要包括：Actionscript,Javascript,PHP,VB,Perl,Delphi,Python,C#,C,Java,C++,Web开发,硬件开发,其它

    热门标签

    Actionscript Javascript PHP VB Perl Delphi Python C# C Java C++ Web开发 硬件开发 其它

    最新资料