这一章说的是一个具体的REST式架构——面向资源的架构(Resource-Oriented Architecture, ROA)。ROA是一种把实际问题转换为REST式Web服务的方法：它令URI、HTTP和XML具有跟其他Web应用一样的工作方式，令程序员们容易是用它们。
这一章将面向资源的架构(ROA)的功能分成：资源、资源名称、资源的表示、资源间的链接。还将介绍ROA的特性：可寻址性(addressability)、无状态性(statelessness)、连通性(connectedness)和统一接口(uniform interface)。
这里有一个容易混淆的地方：为什么有REST了还要用一个ROA呢？REST就是一个指导原则，只要满足REST原则，任何具体的设计都可以成为REST式架构。而ROA就是REST的一个具体的设计架构，可以称之为具体的架构。关于REST的设计原则请参考Roy Fielding的博士论文：《架构风格与基于网络的软件架构设计》及博客：理解本真的REST架构风格。其中总结REST的架构的6个主要的特性如下：
客户-服务器（Client-Server）
通信只能由客户端单方面发起，表现为请求-响应的形式。无状态（Stateless）
通信的会话状态（Session State）应该全部由客户端负责维护。缓存（Cache）
响应内容可以在通信链的某处被缓存，以改善网络效率。统一接口（Uniform Interface）
通信链的组件之间通过统一的接口相互通信，以提高交互的可见性。分层系统（Layered System）
通过限制组件的行为（即，每个组件只能“看到”与其交互的紧邻层），将架构分解为若干等级的层。按需代码（Code-On-Demand，可选）
支持通过下载并执行一些代码（例如Java Applet、Flash或JavaScript），对客户端的功能进行扩展。
这些特性在介绍ROA的时候也会具体详细的介绍。
REST并不依赖于HTTP机制或URI结构，对于特定的服务来说比如Web服务来说明REST，则其具体的表现形式就是HTTP与URI，这些具体的架构形式就称之为ROA架构。如果一个REST式的服务不是基于Web的则可能不叫ROA,但是其遵循的原则都是一致的，只不过表现形式会有一些差别。
什么是资源
这里的定义是：任何事物，只要具有被引用的必要，它就是一个资源(resource)。
资源的具体形式在计算机里就是体现为比特流的事物，如文档、数据库的记录、某程序的运行结果。
URIs
在web里是什么令资源称得上为一个资源呢？那就是它必须至少有一个URI。URI既是资源的地址又是资源的名称，如果一则信息没有URI,那就不能称之为一个资源，而只能算是描述另一个资源的一些数据。
资源与URI的关系式：
URI:资源——> N:1
可寻址性
ROA的第一个特性.这个很好理解，就是每个资源都有自己的URI,这个URI在一定时间内是固定不变的，在有效的时间内用户可以通过URI来找到该资源。
无状态性
ROA的第二个特性.意味着每个HTTP请求都是完全孤立的。这个应该很好理解。
这里还有两个概念：应用状态和资源状态。应用状态是要保存到客户端的，资源状态是保存在服务端的。其实这两个状态是资源与客户端所拥有的资源的状态，每个资源之间是孤立的。
连通性
这个特性是要求资源之间通过它们的表示彼此链接起来。这个特性主要是体现web的易用性。
统一接口
统一接口的意思就是要求对资源的操作要按照REST的要求进行，也就是特定的操作要使用对应的操作方法，而不是混乱的使用。
常用的HTTP方法已经介绍过了，但是有几点需要注意的是
PUT与POST该用哪个？这个是很容易混淆的地方，一般来说POST表示的是增加新的资源，PUT表示修改已有的资源。但是还有下面几个原则：
- 客户端负责决定新资源采用什么URI，就用PUT;服务器负责新资源采用什么URI,那就用POST。
- 对现有资源进行追加信息的时候采用POST。
重载的POST不符合统一接口。
这点并不好理解。其实大部分的时候我们见到的都是这种：它们用POST向一个数据加工处理程序提供数据块（a block of data ）。其中一个最常见的例子就是form表单的提交。这种方法是通过单个HTTP方法表达无数个非HTTP方法。这种重载的POST不应该被用于掩饰拙略的资源设计，这个时候可以通过调整资源设计来做到统一接口。具体如何做，还要等了解再补充。