《ODPS权威指南》1.3 应用开发模式.pdfVIP

《ODPS 权威指南》1.3 应用开发模式 1.4 应用开发模式 要使用 ODPS 服务，用户的应用开发模式如图 1-3 所示。 如图 1-3 所示， ODPS 以 RESTful API 方式对外提供服务，用户可以通过不同的方式 来使用ODPS 的服务：直接通过RESTful API请求访问、ODPS SDK、ODPS CLT （Command Line Tool）和Java 集成开发环境（如 Eclipse）、管理控制台、R 语言集成开发环境（如 RStudio）。 1.4.1 RESTful API ODPS 服务是以 RESTful API 的形式对外提供，所有的客户端组件（SDK、CLT 等）都 是构建在该 API 的语义之上。理解 ODPS RESTful API ，能帮助你理解ODPS 服务，并更 好地掌握如何使用它。关于 RESTful Web 服务的内容，可以写一本书。下面的扩展阅读简 单描述了 RESTful 的核心思想。 什么是 REST？什么又是 RESTful？ REST (REpresentation State Transfer，表述性状态转移) ，是Roy Fielding 博士在其 2000 年 的博士论文中提出来的一种软件架构风格（或称设计原则）。REST 定义了一组体系架构原 则，满足这些原则的应用或设计就是 RESTful。 REST 原则 REST 从资源的角度来观察整个 网络。资源可以理解成是一个 HTTP 对象（即网络上的一个实体），比如某个图片、网页， 这些资源是由 URI 唯一确定，客户端应用通过 URI 获取资源的表现形式。REST 定义了一组 体系架构原则，可以根据这些原则设计以资源为中心的 Web 服务，以及使用各种客户端如 何通过 HTTP 处理和传输资源状态。近年来，REST 已经成为最重要的Web 服务设计模型， 对 Web 影响非常大。 简单而言，REST 原则主要包含以下几点： 通过 URI 标识一个资 源 对资源进行抽象，通过 URI 唯一标识一个资源，且符合用户直觉，比如以下 URI ： /products/odps /wiki/odps /weblog/2011/12/17/1 从上面的 URI，可以很容易理解其含 义。如果/wiki/odps 表示产品 odps 的wiki 说明，那么产品 ecs 的wiki 说明就应该是 /wiki/ecs ，而不应该是/how-to-do/ecs/。这一点也符合前面提到的API 原则：易于学习。 资源必须是可寻址的 资源的可寻址性，也就是说，资源必须是可访问的。从用户角度看， 可寻址性是前提。试想一下，如果资源不具有可寻址性，该资源就不可用，对用户就没有任 何意义。实际上，它就谈不上是 “资源”，而只不过是表示事物的数据而已。可寻址性是 Web 应用的最大优点。 使用标准方法（GET、HEAD、PUT、DELETE、POST） 使用 HTTP 标准方法的语义。HTTP 提供了 9 种请求方法（/ wiki/HTTP）， 其中下面4 种基本方法用于表示 4 种最常见的操作： GET ：获取资源； PUT：向一个 新的 URI 发送 HTTP PUT，则是创建一个新资源；向一个已有URI 发送 HTTP PUT，则是 更新资源； POST：向一个已有URI发送HTTP POST，则是创建一个新资源； DELETE： 删除资源。 HEAD 方法和 GET 方法类似，但不返回响应体。REST 遵循 CRUD 原则，即创 建（Create）、获取（Read）、更新（Update）和删除（Delete），所有的需求都可以 通过这 4 个基本操作组合来满足。 GET 操作满足安全性。所谓安全是指不管执行多少次操 作，资源的状态不会发生改变。比如使用 GET 操作浏览文章，不管浏览多少次，都不会对 文章有任何改变。或许你会想，每浏览一次文章，文章的浏览数就递增，这是改变资源状态 吗？这一点需要透过现象看本质。这个变化不是由 GET 操作引起的，而是由服务端自身的 逻辑，比如定义 Counter 计数来实现的。 GET、PUT 和 DELETE 操作满足幂等性。所谓幂 等是指不管执行多少次操作，结果都是一样的。比如通过 DELETE 操作删除一个资源，它就 不存在了，不管再执行多少次 DELETE 操作，结果还是不存在。通过 PUT 操作创建一个新 的资源，不管再执行多少次，结果都