(读书) RESTful Web Services-中文版-1
第 1 章 Programmable Web及其分类
- 传统网（human web）返回HTML文档。
- 可编程网（programmable web）返回XML文档。
Amazon S3的作用是“在桶（一种带标签的容器）里存放对象（一种带标签的数据）”。
Programmmable web是基于HTTP和XML技术的。
HTTP：信封里的文档
HTTP是一种基于文档的协议。客户端把文档放在信封里，然后发给服务器，作为回应，服务器把响应文档放在信封里，然后发给客户端。
HTTP响应可分为三个部分：
- HTTP响应代码（HTTP response code）
- 相应报头（request headers）
- 实体主体（entity-body）或表示（representation）
XPath介绍利用它，可以方便的将XML文档进行切分。关键的一点是：把XPath表达式看成一种从XML文档里提取标签（tag）或元素（elements）的规则。要知道一个XPath表达式是什么意思，只要从右边往左读就是了。
比如：表达式 //photo 的意思是：
寻找所有photo标签 photo
无论它在文档里何处 //
用REXML::XPath.each(doc,’//photo’)这行简单的Ruby代码可以实现遍历每一个photo标签，而不必遍历整个XML树。
相互竞争的服务架构REST式、面向资源的架构REST式架构意味着，方法信息（method info）都在HTTP方法里；面向资源的架构（ROA）意味着，作用域信息（scoping info）都在URI里。
RPC式架构
RPC架构意味着：方法信息和作用域信息都在信封或报头里，至于具体采用哪种信封，并不影响这里的分类。
XML-RPC是最典型的RPC架构的例子，虽然目前XML-RPC主要是一种遗留协议，但由于相对简单，并且容易理解。
REST-RPC混合架构许多只读的Web服务，尽管他们起初也许是按RPC风格设计的，但都可以称得上是完全REST式和面向资源的。但是，如果该服务允许客户端修改数据的话，就会出现客户端所使用的HTTP方法与真正的方法信息不一致的情况—这样就不具有REST式服务的特征了。这样的服务，称之为REST-RPC服务。
Programmable Web涉及的技术
HTTP URI:一个REST式面向资源的服务为客户端可能操作的每一则数据暴露一个URI；一个REST- RPC混合服务，为客户端可能进行的每一个操作暴露一个URI；一个RPC服务，为每个处理远程调用的进程暴露一个URI。
XML-RPC：是一种用于表达“函数调用及其返回值”的数据结构格式。专用于RPC式Web服务的。
SOAP：一种基于XML格式的信封格式。现在基于SOAP的服务，其SOAP信封里包含的是一个对RPC调用的描述。
WS-:这些标准定义各种特定用途的SOAP报头。
WSDL（服务描述语言）：用于描述SOAP Web服务的XML词汇。客户端通过参考WSDL文档，可以确切地知道它能够调用那些RPC式方法，这些方法需要哪些参数，以及返回值有什么数据类型。
WADL（Web应用描述语言）：用于描述REST式Web服务的XML词汇。
第2章 编写Web服务客户端
Web服务就是网站XPath讲解
以从右到左的顺序来读 /ResultSet/Result/Title/这个表达式，意思是：
寻找直接子节点
谁的直接子节点？ Title标签的 Title/
哪里的Title标签？Result标签下的 Result/
那里的Result标签？ResultSet标签下的 ResultSet/
那里的ResultSet标签？ 文档根目录的 /
用XML解析器处理响应
XML解析器可以分为三种：
有两种基本额你的XML解析策略，基于文档的（document-based）策略（如DOM等树式解析器）和基于事件的（event-based）策略（如SAX及”拖式“（pull）解析器）。
树式解析器把XML文档建模为一种嵌套的数据结构。DOM解析器是一种树式解析器，它实现了一个W3C定义的接口。基于文档的树式策略，树式解析器可以把文档视为一个对象，最大的缺点是：必须把整个文档作为整体来处理。
SAX式或拖式解析器把一个XML文档转换成一个事件流，而不是数据结构。首标签（starting tag）、尾标签（closing tag）、XML注释（comments）、及实体声明（entity declaration）等都是事件（event）。假如几乎每个时间都要处理，那拖式解析器是很有用的。拖式解析器允许你一次处理一个事件。
SAX解析器更为复杂，但它在你只关心部分事件时会很有用。可以向SAX解析器注册一些回调方法，一旦定义好回调方法，解析器将按照既定的、跟文档无关的步骤执行下去：解析器将把XML文档转换为一系列事件，并接连处理文档中的每个事件；每当一个事件与回调方法所对应的事件相匹配时，解析器就会触发该回调方法，执行你定义的代码；在回调方法执行结束后，SAX解析器将接着继续处理事件序列。
基于文档的解析器的优点是：可以随机访问文档中的内容，而对于，基于事件的（event-based）解析器，事件触发之后，就没机会再次处理了。
Ruby: REXMLRuby自带一个标准的XML解析器 — REXML。它同时支持DOM和SAX接口，而且对XPath的支持也很好。遗憾的是，REXML在严格性上处于一种尴尬的位置：它有一定严格性，因此不能指望用它来解析格式有错的XML；但它又没有严格到能拒绝所有格式有错的XML，所以又不能完全信任它的安全性。
如果想确保你只接受良构的XML，需要安装 libxml2库的Ruby语言映射。
如果希望处理格式有错的XML，最佳选择是 hpricot。以 hpricot gem的形式存在，速度比较快，接口比较直观且支持 常见的XPath表达式。
第3章 REST式服务有什么特别从不同？
介绍Simple Storge Service
有两个流行的Web服务能满足这一目的，Atom发布协议（Atom Publishing Protocol, APP）和Amaze S3（Simple Storge Service）。
S3主要被用作两种用途：
1，备份服务器。
2，数据寄存。
S3 的面向对象设计
S3基于2个概念：
S3桶(bucket)和S3对象(object)。一个对象就是一则附有元数据的具名的(named)数据。一个桶(bucket)就是一个用于容纳对象(object)的具名的(named)容器。桶类似于硬盘上的文件系统，对象就类似于系统里的一个文件。桶只可以包含对象，不可以嵌套，只有通过给对象”directory/subdirectory/file-object”式的命名来模拟实现层次结构。
关于桶：
每个S3用户只能创建最多100个桶，而且你的桶不能跟其他用户的桶重名。建议要么把所有对象都放在一个桶里，要么用自己的项目名称或域名来给桶命名。
关于对象： 对象有四个相关部分： 1,对象所在桶的医用。
2,对象里的数据。术语称为value。
3,对象的名称，术语称为key。
4,与对象关联的一组元数据键-值对(metadata key-value pairs)。主要是自定义的元数据，不过也可以包含ContentType和Content-Dispostion等标准的HTTP报头的值。
假如把S3实现为一个面向对象代码库的话，那么将会有S3Bucker和S3Object这2个类，他们各自均有用于数据成员读写的方法。
资源
Amazon S3提供了2种Web服务，基于普通HTTP信封的REST式服务(RESTful service)和基于SOAP信封的RPC服务(RPC-style service)。
1，许多RPC式Web服务都是有它们内部的实现方法(implementation methods)自动生成的，他们暴露的服务接口跟它们在内部调用的编程语言接口是一样的。
2，REST方式暴露的是资源，而不是自己命名的函数。资源(resource)响应的不是像getObject这样自己命名的方法，而是响应GET,HEAD,POST,PUT,DELETE和OPTIONS这些标准的HTTP方法。
REST式S3服务提供三种资源，他们（及相应的URI）分别是： 桶列表(https://s3.amazonaws.com/)：这种类型的资源只有一个；
一个特定的桶(https://s3.amazonaws.com/{name-of-bucket}):这种类型的资源最多有100个。
某个桶里的一个特定的S3对象(https://s3.amazonaws.com/{name-of-bucket}/{name-of-object}):这种类型的资源数量不限。
前面那个假想的面向对象的S3库里的每个方法，都可以转化为上述三种资源和六种标准方法的某种组合。如下：
每个资源都暴露相同的接口，并以同样的方式工作。如果要获取一个对象的值（value），就向该对象的URI发送GET请求，如果只要获取一个对象的元数据（metedata），就向该对象的URI发送HEAD请求，如果需要创建一个桶，就自己构造一个含有桶名的URI，然后向该URI发送PUT请求；如果要往一个桶里添加对象，就向含有桶名和对象名的URI发送PUT请求；如果要删除一个桶或对象，就向其URI发送DELETE请求。
HTTP响应代码
应该充分利用HTTP本身的响应代码。 如200 OK，404 Not Found，403 Forbidden， 400 Bad Request，409 Confilct。更多的请看 iceskysl的。 XPath讲解以从右到左的顺序来读 //Bucket/Name这个XPath表达式，它的意思是： 寻找所有Name标签 Name 那里的Name标签？ 直接在Bucket标签下的 Bucket/ 那里的Bucket标签？任何地方的 //
第4章 面向资源的架构
一个具体的REST式架构 — 面向资源的架构（Resource-Oriented-Architecture, ROA）。ROA是一种把实际问题转换成REST式Web服务的方法：她令URI、HTTP和XML具有跟其他Web应用一样的工作方式，令程序员们容易使用它们。
将介绍面向资源的架构的功能成分：资源、资源名称、资源表示、资源间的链接。 可寻址性 Addressability
可寻址的应用可以为每一则信息都提供一个URI。可以将URI发给其他人，缓存或被加入书签。
无状态性 Statelessness意味着每个HTTP请求都是完全孤立的。
表示 Representations表示的选择 为一个资源的多个表示添加不同的URL。
链接与连通性 links and Connectedness
统一接口 The Uniform Interface
POST
PUT和POST的区别在于：假如是客户端负责决定新资源采用什么URI，就是用PUT；假如是服务器负责新资源采用什么URI，就用POST。
在REST设计中，通常被用于创建从属资源。
第5章 设计只读的面向资源的服务资源设计
面向对象程序的标准设计方法是把系统分解成一个个功能部件，即其中的名词。RPC式架构的设计方法是把系统分解成一个个动作，即其中的动词。 根据需求创建只读资源
1，规划数据集
2，把数据集划分为资源
对于其中的每种资源：
3，用URI为该资源命名
4，设计发给客户端的表示
5，用超链接和表单把该资源与已有资源联系起来
6，考虑有哪些典型的事件经过
7，考虑可能出现哪些错误情况
命名资源
URI设计有三条基本原则：
1，用路径变量（path variables）来表示层次结构（hierarchy）。
2，在路径变量里加上标点符号，以消除误解。当作用域信息的次序有关紧要时，就用逗号。否则就用分号。
3，用查询变量（query variables）来表示算法的输入。
第6章 设计可读写的面向资源的服务
针对上一节的步骤： 添加了2个补充：
4，暴露一个统一接口的子集
5，设计来自客户端的表示
第 7 章 一个服务实现
blog comments powered by Disqus