原文网址：
https://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm

名词释义：

• 表征性：表征（representation）是信息在头脑中的呈现方式。根据信息加工的观点,当有机体对外界信息进行加工（输入、编码、转换、存储和提取等）时，这些信息是以表征的形式在头脑中出现的。
• 体系结构：一组组件以及组件之间的联系
• 可伸缩性/可扩展性（Scalable/Scalability）：设计、开发弹性
• 可见性 指组件监视或调解两个其他组件之间的交互的能力 / 对象间的可见性，含义是一个对象能够看到或者能够引用另一个对象的能力。引申到论文中，理解为组件之间的可交互程度。
• 视图（view）： 数据展示的某种形式，是一个虚拟表。从用户角度来看，一个视图是从一个特定的角度来查看数据库中的数据。
• 属性（property）： 从OOP的思想角度看，属性指对象所拥有的所有具象的内容，例如java中一个类的所有方法和属性等。
• 风格/样式（styles）： 形式，方式，方法。论文中所述应指一组协调的体系结构约束
• 模式（schema）：理解为 较风格具有更高层级，例如设计模式，OOP/POP 等
• 数据粒度（data granularity）：是指数据仓库中数据的细化和综合程度。根据数据粒度细化标准：细化程度越高，粒度越小；细化程度越低，粒度越大。论文中所指的大粒度数据，应指在网络环境过大数据量的背景下，数据粒度应掌握在人类可理解的程度，不宜过于细化数据粒度，过细数据粒度的传输，违反了可见性，可扩展性，简单等原则
• 表示（representative）：资源的表示，包含资源的自描述，资源的uri，资源的元数据以及描述元数据的元数据等，如下是一个完整的资源表示：

1 GET /api/categories
2 Host: www.egoods.com
3 Authorization: Basic xxxxxxxxxxxxxxxxxxx
4 Accept: application/json

• MIME(Multipurpose Internet Mail Extensions):多用途互联网邮件扩展类型。是设定某种扩展名的文件用一种应用程序来打开的方式类型，当该扩展名文件被访问的时候，浏览器会自动使用指定应用程序来打开。多用于指定一些客户端自定义的文件名，以及一些媒体文件打开方式。

Roy Thomas Fielding

第一章 软件架构

1.1 运行时抽象

软件体系结构
软件体系结构是 软件系统在其操作的某个阶段的运行时元素的 抽象。 – 软件体系结构 是 软件系统的 元素 的抽象
系统可以由许多抽象级别和许多操作阶段组成，每个操作阶段都有自己的软件体系结构。
软件架构的核心是抽象原则，通过封装隐藏系统的一些细节，以便更好地识别和维持其属性
这种体系结构的递归继续到最基本的系统元素：那些不能分解成不太抽象的元素。
操作阶段
除了体系结构级别之外，软件系统通常还具有多个操作阶段，例如启动，初始化，正常处理，重新初始化和关闭。每个运营阶段都有自己的架构。
系统架构的整体描述必须不仅能够描述每个阶段期间系统架构的操作行为，还能够描述阶段之间转换的架构。
架构 区别于结构 ： 架构应该能够描述系统的操作行为，并且定义了系统组件间的基本关系 。而结构是源代码的具体结构，他具体实现了系统组件间的关系。所以架构的核心是抽象，更多的含义在于描述。
对于抽象的概念，个人理解为：
1.可定义的，可由元素的特性自由定义
2.描述性的，元素的抽象应能够描述元素的行为和能力
3.本身不具实质功能，仅由隐藏在抽象之下的具体实现实现功能

1.2要素

软件体系结构由体系结构元素（组件，连接器和数据）的配置定义，这些元素在其关系中受到约束，以实现所需的一组体系结构属性。

1.2.1 组件

组件是软件指令和内部状态的抽象单元，通过其接口提供数据转换。

1.2.2连接器

连接器是一种抽象机制，可以调解组件之间的通信，协调或协作。
组件与连接器的对比
考虑连接器的最佳方法可能是将它们与组件进行对比。连接器通过将数据元素从一个接口传输到另一个接口而不更改数据来实现组件之间的通在内部，连接器可以包括组件子系统，该子系统转换数据以进行传输，执行传输，然后反转转换以进行传送。但是，架构捕获的外部行为抽象忽略了这些细节。相反，组件可以（但不总是）从外部角度转换数据。

1.2.3数据

数据是通过连接器从组件传输或由组件接收的信息元素。

1.3配置

配置是系统运行时期间组件，连接器和数据之间的体系结构关系的结构。是交互组件和连接器的集合

1.4属性

软件体系结构 的体系结构属性集 包括从系统内组件，连接器 和 数据的选择和排列中 获得的所有属性。
架构设计的目标是创建一个具有一组架构属性的架构，这些架构构成了系统需求的超集。各种体系结构特性的相对重要性取决于预期系统的性质。

1.5风格 styles

体系结构风格是一组协调的体系结构 约束，它限制了 体系结构元素的角色/特征以及符合该风格的任何体系结构中这些元素之间允许的关系。
样式是一种机制，用于对体系结构进行分类并定义它们的共同特征
一些体系结构风格通常被描述为适用于所有形式软件的“银弹”解决方案。但是，优秀的设计师应该选择符合要解决的特定问题需求的风格。为基于网络的应用程序选择正确的架构风格需要了解问题域，从而了解应用程序的通信需求，了解各种架构风格及其解决的特定问题，以及预测的能力每种交互方式对基于网络的通信特征的敏感性

1.6模式和模式语言 1.6 Patterns and Pattern Languages

模式的设计空间包括特定于面向对象编程技术的实现问题，例如类继承和接口组合，以及架构风格所解决的更高级别的设计问题。
换句话说，模式通过遵循设计和实现选择的路径来定义解决问题的过程
大体上 理解为设计模式，比如面向对象 OOP 面向过程

1.7视图 views

Perry和Wolf [105]描述了软件架构中的三个重要观点：处理，数据和连接视图。流程视图强调通过组件的数据流以及组件之间关于数据的连接的某些方面。数据视图强调处理流程，而不太重视连接器。连接视图强调组件之间的关系和通信状态。
在特定架构的案例研究中，多种架构视图很常见。一种架构设计方法，即4 + 1视图模型，使用五个并发视图组织软件架构的描述，每个视图解决一组特定的问题。

第二章 基于网络的应用程序架构

2.1范围 scope

本小节 博士 说明了 论文讨论的范围 是基于网络与分布式，限于应用程序体系结构。并对分布式系统和基于网络的系统进行了区分：分布式系统是一种向普通集中式系统看待其用户但在多个独立CPU上运行的系统。相反，基于网络的系统是能够跨网络操作的系统

2.2评估应用程序体系结构的设计

架构设计很难以客观的方式进行评估和比较
第一级评估由应用程序的功能要求设置
每个架构设计决策都可以看作是一种风格的应用
由于添加约束可以派生出新的样式，我们可以将所有可能的架构样式的空间视为派生树
本节提出了架构风格是一组协调的架构约束，并通过约束的新增提出了层级的派生树的观点，在架构设计的时候由简到繁，林立一副完整的架构样式树结构，可以使架构的整体设计更加清晰，在特定需求的情况下，使得选择能够满足应用程序需求的架构变得更加便捷。也可以通过设定权重值的方式来明确衡量标准。

2.3关键利益的体系结构特性

本节描述了本文中用于区分和分类架构风格的架构属性。
2.3.1性能
软件无法避免实现应用需求的基本成本，例如：数据处理成本，数据交互成本，数据存储成本等等
2.3.1.1网络性能
网络性能度量用于描述通信的某些属性。
吞吐量是在组件之间传输信息（包括应用程序数据和通信开销）的速率。
开销可以分为初始设置开销和每个交互开销，这一区别对于识别可以跨多个交互（摊销）共享设置开销的连接器很有用。
带宽是给定网络链路上最大可用吞吐量的度量。
可用带宽是指应用程序实际可用的带宽部分。
小数据，估计小型强类型交互， 但是大数据中将导致过多的开销。
2.3.1.2用户感知的性能
用户感知的性能与网络性能的不同之处在于，动作的性能是根据其在应用程序前对用户的影响而不是网络移动信息的速率来衡量的。
用户感知性能的主要衡量标准是延迟和完成时间。
例如，可以在接收大图像时呈现大图像的Web浏览器提供比在呈现之前等待整个图像完全接收的图像明显更好的用户感知性能，即使两者都经历相同的网络性能。
值得注意的是，优化延迟的设计考虑通常会产生降低完成时间的副作用，反之亦然。
例如，如果算法在产生编码变换之前对大部分数据进行采样，则数据流的压缩可以产生更有效的编码，从而导致在网络上传输编码数据的完成时间更短。但是，如果响应用户操作而即时执行此压缩，则在传输之前缓冲大样本可能会产生不可接受的延迟。
2.3.1.3网络效率
关于基于网络的应用程序的一个有趣的观察是，通过不使用网络可以获得最佳的应用程序性能。这实际上意味着基于网络的应用程序的最有效的架构风格是那些可以通过重用先前的交互（缓存），减少网络交互频率来有效地最小化网络使用的架构风格。
2.3.2可扩展性
可伸缩性是指体系结构在活动配置中支持大量组件或组件之间的交互的能力。通过简化组件，在多个组件之间分配服务（分散交互）以及通过监视来控制交互和配置，可以提高可伸缩性。轻耦合
2.3.3简单
架构风格引起简单性的主要手段是将关注点分离原则应用于组件内功能的分配。如果可以分配功能使得各个组件基本上不那么复杂，那么它们将更容易理解和实现。
这种分离简化了关于整体架构的推理任务，提高了可理解性和可验证性的质量。
2.3.4可修改性
可修改性是指可以轻松地对应用程序体系结构进行更改。
2.3.4.1进化性
Evolvability表示可以在不对其他组件产生负面影响的情况下更改组件实现的程度。组件的静态演化通常取决于实现对架构抽象的执行程度，因此不是任何特定架构风格的独特之处。
2.3.4.2可扩展性
可扩展性定义为向系统添加功能的能力[ 108 ]。
2.3.4.3可定制性
可定制性是指临时专门化架构元素行为的能力，以便它可以执行异常服务。
2.3.4.4可配置性
可配置性与可扩展性和可重用性相关，因为它指的是组件的部署后修改或组件的配置，使得它们能够使用新的服务或数据元素类型。
2.3.4.5可重用性
可重用性是应用程序体系结构的一种属性，如果其组件，连接器或数据元素可以在其他应用程序中重复使用而无需修改。
2.3.5可见性
样式还可以通过一般性限制接口 或 提供对监视的访问 来影响基于网络的应用程序内交互的可见性。
在这种情况下，可见性是指组件监视或调解两个其他组件之间的交互的能力。
2.3.6便携性
如果软件可以在不同的环境中运行，则它是可移植的。
2.3.7可靠性
从应用程序体系结构的角度来看，可靠性可视为在组件，连接器或数据中存在部分故障时，体系结构易受系统级故障影响的程度。

2.4总结

本章通过关注基于网络的应用程序体系结构并描述如何使用样式来指导其体系结构设计来检查论文的范围。它还定义了一组架构属性，这些属性将在整个论文的其余部分中用于比较和评估架构风格。

第三章 基于网络的体系结构风格

3.1分类方法

本节作者主要阐述了他选择网络体系结构风格的依据
1.具备代表性的，典型的
2.排除了混合风格
同时，也阐述了风格的相对性，即典型和混合是相对的，一个典型风格的特点也是相对于其他具典型风格而言
额，接下来的部分，恕在下才疏学浅，看不懂。有兴趣的可以去查看原文
本章介绍了一种分类框架中基于网络的应用软件的常见架构风格的调查，该框架根据应用于基于原型网络的超媒体系统的架构时将引发的架构属性来评估每种样式。整体分类总结如下表3-6。
表值指示给定行的样式对列属性的相对影响。负（-）符号为负影响累加，加（+）符号为正，负正（±）表示它取决于问题域的某些方面。虽然这是对每个部分中详细介绍的细节的粗略简化，但它确实表明了样式处理（或忽略）架构属性的程度。

第四章 设计Web架构：问题和见解

4.1 WWW应用程序域要求

伯纳斯 - 李写道，“网络的主要目标是成为人和机器可以通信的共享信息空间。”
本节作者主要阐述了web 应用程序域的要求
4.1.1低入口障碍 是低入口障碍，即简单、通用，可以使用现有的开发软件进行读写，主要要求是整个系统的部分可用性不得妨碍内容的创作。
4.1.2 可扩展性，可修改的，可完善的，可定制的。
4.1.3 分布式超媒体 超媒体的定义是信息呈现中嵌入的应用程序控制信息的存在，或者作为上层的信息呈现。分布式超媒体允许将演示和控制信息存储在远程位置。就其本质而言，分布式超媒体系统内的用户动作需要将大量数据从存储数据的位置传输到使用它的位置。因此，Web架构必须设计用于大粒度数据传输。
原文(large-grain data transfer) 数据粒度，是指数据仓库中数据的细化和综合程度。根据数据粒度细化标准：细化程度越高，粒度越小；细化程度越低，粒度越大。
可以参考博文详解粒度的含义 https://bbs.****.net/topics/340190369?page=1
超媒体交互的可用性对用户感知的延迟高度敏感：选择链接和呈现可用结果之间的时间。由于Web的信息源分布在全球Internet上，因此架构需要最小化网络交互（数据传输协议内的往返）
4.1.4达到互联网规模，信息服务的供应商必须能够应对无政府可扩展性和软件组件的独立部署的需求。
4.1.4.1无状态可扩展性 无状态可扩展性是指架构元素在遭受意外负载时，或者在给定格式错误或恶意构造的数据时，需要继续运行，因为它们可能与组织控制之外的元素进行通信。该体系结构必须适用于增强可见性和可伸缩性的机制。
无状态可扩展性要求适用于所有架构元素。不能期望客户端保持所有服务器的知识。不能期望服务器保持跨请求的状态知识。
体系结构元素的安全性以及它们运行的​​平台也成为一个重要的问题。多个组织边界意味着任何通信中都可能存在多个信任边界。中间件应用程序（例如防火墙）应该能够检查应用程序交互并防止对组织安全策略之外的人员采取行动。应用程序交互的参与者应该假定所接收的任何信息都是不可信的，或者在获得信任之前需要一些额外的身份验证。这要求架构能够传递认证数据和授权控制。然而，由于身份验证降低了可伸缩性，体系结构的默认操作应该仅限于不需要可信数据的操作:一组具有定义良好语义的安全操作。
4.1.4.2独立部署 多个组织边界还意味着系统必须为渐进和分散的变更做好准备，新旧实现共存，而不会阻止新实现利用其扩展功能。需要设计现有的架构元素，期望将添加以后的架构特征。同样，需要轻松识别较旧的实现，以便可以封装遗留行为，而不会对新的体系结构元素产生负面影响。整个体系结构必须设计为以部分，迭代的方式简化体系结构元素的部署，因为不可能以有序的方式强制部署。

4.2 问题：

大体阐述为网络使用的过快增长，和各类风格、样式的使用，没有统一的风格和标准使得隐患的存在，尽管Internet工程任务组内的工作组成立于Web的三个主要标准：URI，HTTP和HTML。但仍需要一组约束来规范网络应用开发

4.3方法

早期的Web架构基于可靠的原则 - 关注点分离，简单性和通用性 - 但缺乏架构描述和基本原理。
可以使用体系结构样式来定义Web体系结构背后的原则，因此，我的方法的第一步是确定早期Web体系结构中对其所需属性负责的约束。
假设I：WWW体系结构背后的设计原理可以通过一种体系结构样式来描述，该体系结构样式由应用于Web体系结构中的元素的约束集组成。
假设II：可以将约束添加到WWW体系结构样式中，以获得更好地反映现代Web体系结构所需属性的新混合样式。
假设III：可以将修改Web体系结构的提议与更新的WWW体系结构样式进行比较，并在部署之前分析冲突。

4.4总结

本章介绍了万维网体系结构的要求以及设计和评估其关键通信协议的改进建议所面临的问题。面临的挑战是开发一种设计架构改进的方法，以便在部署之前评估改进。我的方法是使用体系结构样式来定义和改进Web体系结构背后的设计原理，使用该样式作为在部署之前证明建议扩展的酸测试，并通过直接参与软件开发来部署修订的体系结构已创建Web基础结构的项目。

第五章 表征性状态转移 Representational State Transfer（REST）

本章介绍和阐述了分布式超媒体系统的表征性状态转移（REST）架构风格，描述了指导REST的软件工程原理以及为保留这些原则而选择的交互约束，同时将它们与其他架构风格的约束进行了对比。REST是一种混合风格，它源自第3章中描述的几种基于网络的体系结构样式，并结合了定义统一连接器接口的其他约束。第1章的软件体系结构框架用于定义REST的体系结构元素，并检查原型体系结构的样本过程，连接器和数据视图。

5.1派生REST

Web体系结构背后的设计原理可以通过体系结构样式来描述，该体系结构样式由应用于体系结构中的元素的约束集组成。
通过检查每个约束添加到不断变化的样式时的影响，我们可以识别由Web约束引起的属性。
然后可以应用其他约束来形成新的体系结构样式，以更好地反映现代Web体系结构的所需属性。
本节通过介绍将其作为架构风格派生的过程，提供REST的一般概述。后面的部分将更详细地描述组成REST样式的特定约束。
5.1.1从Null样式开始
设计师从零开始 - 空白的板岩，白板或绘图板 - 并从熟悉的组件构建架构，直到满足预期系统的需求。
第二个是设计人员从系统需求开始，没有约束，然后逐步识别并应用系统元素的约束，以区分设计空间，并允许影响系统行为的力自然地流动，与系统和谐相处。第一个强调创造力和无限视觉，第二个强调对系统环境的约束和理解。使用后一种方法开发了REST。
Null样式（图5-1）只是一组空的约束。从体系结构的角度来看，null样式描述了一个系统，其中组件之间没有明显的边界。它是我们描述REST的起点。
5.1.2 客户端 - 服务器
关注点分离是客户端 - 服务器约束背后的原则。通过将用户界面问题与数据存储问题分开，我们提高了跨多个平台的用户界面的可移植性，并通过简化服务器组件来提高可伸缩性。
5.1.3 无状态
此约束会导致可见性，可靠性和可伸缩性。可见性得到改善，因为监控系统不必超出单个请求数据，以确定请求的完整性质。可靠性得到改善，因为它简化了从部分故障中恢复的任务。可扩展性得到改善，因为不必在请求之间存储状态允许服务器组件快速释放资源，并进一步简化实现，因为服务器不必管理跨请求的资源使用。
5.1.4缓存
高速缓存约束要求将对请求的响应中的数据隐式或显式标记为可高速缓存或不可高速缓存。如果响应是可缓存的，则客户端缓存有权重用该响应数据以用于以后的等效请求。
添加缓存约束的优势在于，它们有可能通过减少一系列交互的平均延迟来部分或完全消除某些交互，从而提高效率，可伸缩性和用户感知性能。然而，权衡的是，如果高速缓存中的陈旧数据与请求已直接发送到服务器时获得的数据显着不同，则高速缓存会降低可靠性。
5.1.5统一接口
将REST架构风格与其他基于网络的风格区分开来的核心功能是强调组件之间的统一接口。
5.1.6分层系统
分层系统的主要缺点是它们增加了数据处理的开销和延迟，降低了用户感知的性能，但他极大的提高了可扩展性。
例如一次完整web请求-响应流程，经历了客户端、客户端连接器、用户代理、网关、服务器等多个层级，层级之间的低耦合性和关注点分离特性极大的提高了系统的可扩展性和灵活性。
5.1.7按需代码
5.1.8样式派生摘要

5.2 REST架构元素

Representational State Transfer（REST）风格是分布式超媒体系统中的架构元素的抽象。REST忽略了组件实现和协议语法的细节，以便专注于组件的角色，与其他组件交互的约束以及对重要数据元素的解释。它包含对组件，连接器和数据的基本约束，这些约束定义了Web体系结构的基础，因此也就是其作为基于网络的应用程序的行为的本质。
5.2.1数据元素
与分布式对象样式不同，其中所有数据都封装在处理组件中并由处理组件隐藏，架构的数据元素的性质和状态是REST的一个关键方面。
分布式超媒体架构师只有三个基本选项：
1）渲染数据所在的位置，并向接收者发送固定格式的图像; 地址的发送，io传输等
传统的客户端 - 服务器风格，允许所有关于数据真实性质的信息保持隐藏在发送者中，从而防止对数据结构做出假设并使客户端实现更容易。但是，它还严重限制了收件人的功能，并将大部分处理负载放在发件人身上，从而导致可伸缩性问题。
2）用渲染引擎封装数据并将它们发送给接收者; 数据封装，视界层展示
移动对象样式，提供信息隐藏，同时通过其独特的渲染引擎实现数据的专门处理，但是将接收者的功能限制在该引擎内预期的内容，并且可能极大地增加传输的数据量。
我们平常的项目开发应是使用这种方式
3）将原始数据与描述数据类型的元数据一起发送给接收者，以便接收者可以选择他们自己的呈现引擎。 数据的描述及传输，example： api接口联调
允许发送者保持简单和可扩展，同时最小化传输的字节，但是失去了信息隐藏的优点，并且要求发送者和接收者都理解相同的数据类型
REST的数据元素总结：

5.2.1.1资源和资源标识符
首先可以了解一下URI（uniform resource identifier） / URL （uniform resource location） / URN （uniform resource name）http://web.jobbole.com/83452/
REST中信息的关键抽象是一种资源。可以命名的任何信息都可以是资源：文档或图像，临时服务（例如“洛杉矶的今天天气”），其他资源的集合，非虚拟对象（例如人）等等。
任何可能是作者超文本引用目标的概念都必须符合资源的定义。资源是到一组实体的概念映射，而不是与任何特定时间点的映射相对应的实体。
资源是实体的映射，而不是映射对应的实体。
体现在接口上，假设有一个接口提供打印服务，那么代码中可能存在打印机的实体对象，但若不对打印机进行参数维护，仅提供打印机打印的服务接口，那么打印服务就是一个资源，而打印机实体本身不是资源
对于资源而言，唯一需要静态的是映射的语义，因为语义是区分一个资源与另一个资源的区别。
无论通过资源得到的结果是否一致，重要的是通过语义的不同区分资源本身的不同。
资源的这种抽象定义实现了Web体系结构的关键功能。首先，它通过包含许多信息来源提供了一般性，而没有按类型或实施人为地区分它们。其次，它允许将引用后期绑定到表示，从而允许基于请求的特征进行内容协商。最后，它允许作者引用该概念而不是该概念的某些单一表示，从而无需在表示发生变化时更改所有现有链接（假设作者使用了正确的标识符）。
这一段理解为，资源的抽象定义使得不必针对定义背后的某些特性去定义资源，从而使得在接口后的实现发生变化时，资源链接无需进行改变。
5.2.1.2表示（Representations）
REST组件通过使用资源的Representations捕获该资源的当前或预期状态并在组件之间传输该资源的Representations来对资源执行操作。表示是字节序列，加上用于描述这些字节的Representations元数据。其他常用但不太精确的表示名称包括：文档，文件和HTTP消息实体，实例或变体。
Representations由数据，描述数据的元数据以及有时描述元数据的元数据（通常用于验证消息完整性）组成。元数据采用名称 - 值对的形式，其中名称对应于定义值的结构和语义的标准。响应消息可以包括表示元数据和资源元数据：关于不是特定于所提供的表示的资源的信息。
5.2.2连接器
REST使用表5-2中汇总的各种连接器类型来封装访问资源和传输资源表示的活动。

连接器为组件通信提供了一个抽象接口，通过提供关注点的清晰分离和隐藏资源和通信机制的底层实现来增强简单性。接口的通用性还具有可替代性：如果用户只能通过抽象接口访问系统，则可以在不影响用户的情况下替换实现。由于连接器管理组件的网络通信，因此可以跨多个交互共享信息，以便提高效率和响应能力。
所有REST交互都是无状态的。每个请求都包含连接器理解请求所需的所有信息，与之前可能存在的任何请求无关
此限制实现了四个功能：
1）它消除了连接器在请求之间保留应用程序状态的任何需要，从而减少了物理资源的消耗并提高了可伸缩性;
2）它允许并行处理交互，而不需要处理机制理解交互语义;
3）它允许中介单独查看和理解请求，这在动态重新安排服务时可能是必要的;
4）它强制所有可能影响缓存响应的可重用性的信息出现在每个请求中。
5.2.3组件
表5-3中 汇总的REST组件按其在整个应用程序操作中的角色进行键入。

用户代理使用客户端连接器来发起请求，并成为响应的最终接收者。最常见的示例是Web浏览器，它提供对信息服务的访问并根据应用程序需求呈现服务响应。
源服务器使用服务器连接器来管理所请求资源的命名空间。它是表示其资源的权威来源，必须是任何打算修改其资源价值的请求的最终接收者。每个源服务器都将其服务的通用接口作为资源层次结构提供。资源实现细节隐藏在界面后面。
中介组件既作为客户又作为服务器，以便转发可能的翻译，请求和响应。
代理组件是客户端选择的中介，用于提供其他服务的接口封装，数据转换，性能增强或安全保护。
网关（也称为反向代理）组件是由网络或源服务器强加的中介，以提供其他服务的接口封装，用于数据转换，性能增强或安全实施。请注意，代理和网关之间的区别在于客户端确定何时使用代理。

5.3 REST架构视图

5.3.1流程视图

体系结构的过程视图主要通过揭示数据流经系统时的路径来引发组件之间的交互关系。
REST的客户端 - 服务器关注点分离简化了组件实现，降低了连接器语义的复杂性，提高了性能调优的效率，并提高了纯服务器组件的可伸缩性。
分层系统约束允许在通信中的各个点处引入中介 - 代理，网关和防火墙 - 而不改变组件之间的接口，从而允许它们通过大规模共享缓存来协助通信转换或提高性能。
REST通过将消息约束为自描述来实现中间处理：交互在请求之间是无状态的，标准方法和媒体类型用于指示语义和交换信息，并且响应明确指示可缓存性。
重点：本节体现了至少四点REST约束
客户端 - 服务器关注点分离约束
分层系统约束
资源表示自描述约束
交互无状态约束
5.3.2连接器视图
体系结构的连接器视图集中于组件之间的通信机制。
客户端连接器检查资源标识符，以便为每个请求选择适当的通信机制。
REST不限制与特定协议的通信，但它确实限制了组件之间的接口，因此限制了组件之间可能产生的交互和实现假设的范围。
5.3.3数据视图
体系结构的数据视图揭示了信息流经组件时的应用程序状态。
由于REST专门针对分布式信息系统，因此它将应用程序视为信息和控制备选方案的紧密结构，用户可通过该结构执行所需任务。
体系结构的数据视图揭示了信息流经组件时的应用程序状态。由于REST专门针对分布式信息系统，因此它将应用程序视为信息和控制备选方案的紧密结构，用户可通过该结构执行所需任务。例如，在在线词典中查找单词是一个应用程序，如在虚拟博物馆中巡回演出，或者查看一组课堂笔记以进行考试。每个应用程序都定义了底层系统的目标，可以根据这些目标来衡量系统的性能。
组件交互以动态大小的消息的形式发生。小型或中型消息用于控制语义，但大部分应用程序工作是通过包含完整资源表示的大粒度消息来完成的。最常见的请求语义形式是检索资源的表示（例如，HTTP中的“GET”方法），其通常可以被缓存以供以后重用。
REST将所有控制状态集中到响应交互所接收的表示中。
由于基于REST的体系结构主要通过资源表示的传递进行通信，因此延迟可能受到通信协议的设计和表示数据格式的设计的影响。
一个有趣的观察是，最有效的网络请求是不使用网络的请求。换句话说，重用缓存响应的能力可以显着提高应用程序性能。
应用程序的下一个控制状态驻留在第一个请求资源的表示中，因此获得第一个表示是优先级。因此，通过“先响应并稍后思考”的协议来改进REST交互。换句话说，每个用户操作需要多次交互的协议，以便在发送内容响应之前执行诸如协商功能功能之类的操作，将比发送最可能首先发送的任何内容然后提供的协议慢得多。如果第一个响应不令人满意，客户端检索的备选列表。
将以此请求-响应设计为多次请求-响应的方式，这里指的是协议传输以及连接器交互机制的改进，我们也可以类比到我们的项目开发中，例如我们项目开发中的具权限控制的文件下载

5.4相关工作

5.5总结

本章介绍了分布式超媒体系统的Representational State Transfer（REST）架构风格。
REST提供了一组体系结构约束，当作为一个整体应用时，强调组件交互的可伸缩性，接口的通用性，组件的独立部署以及中间组件，以减少交互延迟，实施安全性并封装遗留系统。

第六章经验和评估

自1994年以来，REST架构风格已被用于指导现代Web架构的设计和开发。
本章介绍了在创建 超文本传输​​协议（HTTP）和统一资源标识符（URI） 的Internet标准时 应用REST所获得的经验和教训，这两个规范定义了Web上所有组件交互使用的通用接口，以及以libwww-perl客户端库，Apache HTTP Server Project和协议标准的其他实现形式部署这些技术。

6.1标准化Web

REST开发初衷：开发REST的动机是为Web应该如何工作创建一个架构模型，以便它可以作为Web协议标准的指导框架。
REST已应用于描述所需的Web体系结构，帮助识别现有问题，比较替代解决方案，并确保协议扩展不会违反使Web成功的核心约束。这项工作是作为Internet工程任务组（IETF）和万维网联盟（W3C）为Web定义架构标准（HTTP，URI和HTML）的一部分而完成的。
名称“Representational State Transfer”旨在唤起设计良好的Web应用程序行为的图像：网页网络（虚拟状态机），用户通过选择链接（状态转换）在应用程序中前进，

6.2 REST应用于URI

统一资源标识符（URI）既是Web架构中最简单的元素，也是最重要的元素。
URI已被许多名称所知：
WWW地址，
通用文档标识符，
统一资源标识符，统一资源定位符（URL）
名称（URN）。
REST用于定义URI标准的术语资源，以及通过其表示操作资源的通用接口的整体语义
6.2.1资源的重新定义
早期的Web架构将URI定义为文档标识符。指示作者根据文档在网络上的位置定义标识符。然后可以使用Web协议来检索该文档。
缺点：
1 它表明作者正在识别传输的内容，这意味着只要内容发生变化，标识符就会发生变化。
2 存在许多与服务而不是文档相对应的地址 - 作者可能打算将读者引导到该服务，而不是通过先前访问该服务的任何特定结果。
3 在某些时间段存在与文档不对应的地址，
REST中资源的定义基于一个简单的前提：标识符应尽可能不经常更改。
因为Web使用嵌入式标识符而不是链接服务器，所以作者需要一个与超媒体引用紧密匹配的语义标识符，允许引用保持静态，即使访问该引用的结果可能随时间而变化。REST通过将资源定义为作者想要识别的语义来实现这一点，而不是在创建引用时与这些语义相对应的值。
6.2.2操纵阴影
定义资源使得URI标识概念而不是文档会给我们留下另一个问题：用户如何访问，操作或转移概念，以便在选择超文本链接时可以获得有用的东西？REST通过定义被操纵的事物来回答该问题，这些事物是所识别资源的表示，而不是资源本身。
源服务器维护从资源标识符到对应于每个资源的表示集的映射。因此，通过通过资源标识符定义的通用接口传送表示来操纵资源。
REST对资源的定义源于Web的核心要求：跨多个信任域独立创建互连超文本。强制接口定义与接口要求相匹配会导致协议看起来模糊，但这只是因为被操作的接口只是一个接口而不是一个实现。协议特定于应用程序操作的意图，但接口背后的机制必须决定该意图如何影响资源映射到表示的底层实现。
6.2.3远程创作
资源不是存储对象。资源不是服务器用于处理存储对象的机制。
资源是概念映射 - 服务器接收标识符（标识映射）并将其应用于其当前映射实现（通常是特定于集合的深层树遍历和/或散列表的组合）以查找当前负责的处理程序然后，实现和处理程序实现根据请求内容选择适当的操作+响应。所有这些特定于实现的问题都隐藏在Web界面之后; 它们的性质不能由只能通过Web界面访问的客户端承担。
6.2.4将语义绑定到URI
如上所述，资源可以具有许多标识符。
换句话说，当用于访问服务器时，可能存在两个或更多个具有等效语义的不同URI。
也可能有两个URI导致在访问服务器时使用相同的机制，但这些URI标识两个不同的资源，因为它们并不意味着相同的事情。
语义是分配资源标识符并用表示填充这些资源的行为的副产品。在任何时候，服务器或客户端软件都不需要知道或理解URI的含义 - 它们只是作为一个管道，资源的创建者（人类命名机构）可以通过该管道将表示与由表示的语义相关联。 URI。
换句话说，服务器上没有资源; 只是通过资源定义的抽象接口提供答案的机制。这可能看起来很奇怪，但这是使Web在许多不同实现中工作的本质。
6.2.5 URI中的REST不匹配
与大多数现实世界系统一样，并非所部署的Web体系结构的所有组件都遵循其体系结构设计中存在的每个约束。
REST已被用作定义体系结构改进和识别体系结构不匹配的手段。
当由于无知或疏忽而部署了违反架构约束的软件实现时，会发生不匹配。虽然通常无法避免不匹配，但可以在它们变得标准化之前识别它们。

6.3 REST应用于HTTP

这一段讲了很多HTTP的的底层知识，确实不太好理解，都是截取原文内容，想了解的可以查阅原文。
超文本传输​​协议（HTTP）在Web体系结构中具有特殊的作用，它既是Web组件之间通信的主要应用程序级协议，也是专门为资源表示传输而设计的唯一协议。
与URI不同，为了支持现代Web架构，需要进行大量更改。HTTP实现的开发人员在采用提议的增强功能时一直保守，因此扩展需要在部署之前进行验证并进行标准审查。REST用于识别现有HTTP实现的问题，将该协议的可互操作子集指定为HTTP / 1.0，分析HTTP / 1.1的建议扩展，并提供部署HTTP / 1.1的激励理由。
6.3.1可扩展性
REST的主要目标之一是支持在已部署的体系结构中逐步和分散的更改部署。
6.3.1.1协议版本控制
HTTP是一系列协议，由主要版本号和次要版本号区分，它们共享名称主要是因为它们对应于直接与基于“http”URL命名空间的服务进行通信时所期望的协议。连接器必须遵守每条消息中包含的HTTP版本协议元素的约束
HTTP包括许多单独的命名空间，每个命名空间都有不同的约束，但所有这些命名空间都共享无限制可扩展的要求。
一些命名空间由单独的Internet标准管理并由多个协议共享（
例如，
URI方案，
媒体类型，
MIME头字段名称，
字符集值，语言标签），
而其他名称由HTTP，包括方法名称的命名空间，响应状态代码，非MIME标头字段名称以及标准HTTP标头字段中的值。
通过将用于解析和转发HTTP消息的规则与与新HTTP协议元素相关联的语义分开来解决此部署问题。
例如，HEAD是Content-Length头字段具有除表示消息体长度之外的含义的唯一方法，并且没有新方法可以更改消息长度计算。
GET和HEAD也是条件请求头字段具有缓存刷新语义的唯一方法，而对于所有其他方法，它们具有前置条件的含义。
6.3.2自描述信息
REST将组件之间的消息限制为自描述的，以支持交互的中间处理。
6.3.2.1主机
6.3.2.2分层编码
HTTP继承了其用于描述多用途Internet邮件扩展（MIME）中的表示元数据的语法。MIME不定义分层媒体类型，而是优选仅在Content-Type字段值中包含最外层媒体类型的标签。
6.3.2.3语义独立性
如上所述，HTTP消息解析已与其语义分离。消息解析（包括查找和汇总头字段）完全独立于解析头字段内容的过程。
6.3.2.4运输独立性
早期HTTP（包括HTTP / 1.0的大多数实现）使用底层传输协议作为发送响应消息结束信号的手段。服务器将通过关闭TCP连接来指示响应消息正文的结束。遗憾的是，这在协议中造成了严重的失败情况：客户端无法区分已完成的响应和因某些错误的网络故障而被截断的响应。为了解决这个问题，Content-Length头字段在HTTP / 1.0中被重新定义，以指示消息体长度（以字节为单位），无论何时预先知道长度，并且“chunked”传输编码被引入HTTP / 1.1。
分块编码允许在其生成开始时（当发送报头字段时）大小未知的表示，以使其边界由一系列块描绘，这些块在发送之前可以单独地大小。它还允许在消息末尾将元数据作为预告片发送，从而在生成消息时在原点创建可选元数据，而不会增加响应延迟。
6.3.2.5尺寸限制
HTTP协议对URI的长度，头字段的长度，表示的长度或由项列表组成的任何字段值的长度没有限制。
6.3.2.6缓存控制
于REST试图平衡对高效，低延迟行为的需求与对语义透明缓存行为的需求，因此HTTP允许应用程序确定缓存要求而不是将其硬编码到协议本身中至关重要。
6.3.2.7内容协商
所有资源都将请求（包括方法，标识符，请求标题字段，有时是表示）映射到响应（包含状态代码，响应标头字段，有时还包括表示）。
当HTTP请求映射到服务器上的多个表示时，服务器可以与客户端进行内容协商，以确定哪个最符合客户的需求。这实际上比谈判更像是一个“内容选择”过程。
6.3.3性能
HTTP / 1.1侧重于改进组件之间通信的语义，但是对用户感知性能也有一些改进，尽管受到与HTTP / 1.0的语法兼容性要求的限制。
6.3.4 HTTP中的REST不匹配
HTTP中存在一些架构不匹配，一些是由于部署在标准流程外部的第三方扩展，另一些是由于必须保持与部署的HTTP / 1.0组件兼容。
6.5.4.3 Java与JavaScript
REST还可用于深入了解为什么某些媒体类型在Web架构中的使用率高于其他媒体类型，即使开发者意见的平衡不利于他们。Java applet与JavaScript的案例就是一个例子。
Java TM [ 45 ]是一种流行的编程语言，最初是为电视机顶盒中的应用程序开发的，但是当它被引入Web作为实现按需代码功能的手段时，它首先获得了声名狼借。尽管该语言得到了其所有者Sun Microsystems，Inc。的大量媒体支持，以及寻求替代C ++语言的软件开发人员的好评如潮，但它未能被应用程序开发人员广泛采用，以满足代码需求。在网络内。
在Java推出后不久，Netscape Communications Corporation的开发人员为嵌入式按需代码创建了一种单独的语言，最初称为LiveScript，但后来由于市场原因而改为JavaScript名称（两种语言除此之外几乎没有共同点）[ 44 ]。虽然最初被嘲笑为嵌入了HTML但与正确的HTML语法不兼容，但自从推出以来，JavaScript的使用率一直在稳步增长。
问题是：为什么JavaScript在Web上比Java更成功？它当然不是因为它的技术质量作为一种语言，因为与Java相比，它的语法和执行环境都被认为是差的。这也不是因为市场营销：Sun在这方面远远超过Netscape，并且还在继续这样做。这并不是因为语言的任何固有特性，因为Java在所有其他编程领域（独立应用程序，servlet等）中比JavaScript更成功。为了更好地理解这种差异的原因，我们需要根据其特性评估Java作为REST中的表示媒体类型。
JavaScript更适合Web技术的部署模型。它的入门门槛要低得多，无论是作为一种语言的整体复杂程度还是新手程序员整理第一段工作代码所需的初始工作量。JavaScript对交互的可见性影响也较小。独立组织可以像复制HTML一样阅读，验证和复制JavaScript源代码。相反，Java是作为二进制打包存档下载的 - 因此用户可以信任Java执行环境中的安全限制。同样，Java还有许多在安全环境中被认为有问题的功能，包括将RMI请求发送回原始服务器的能力。RMI不支持中介机构的可见性。
然而，两者之间最重要的区别可能是JavaScript导致较少的用户感知延迟。JavaScript通常作为主要表示的一部分下载，而Java applet则需要单独的请求。Java代码一旦转换为字节代码格式，就比典型的JavaScript大得多。最后，虽然可以在下载HTML页面的其余部分时执行JavaScript，但Java要求在应用程序开始之前下载并安装完整的类文件包。因此，Java不支持增量渲染。
一旦语言的特征与REST约束的基本原理相同，就可以更容易地根据现代Web架构中的行为来评估技术。

6.6总结

本章描述了在创建超文本传输​​协议（HTTP）和统一资源标识符（URI）的Internet标准时应用REST所获得的经验和教训。这两个规范定义了Web上所有组件交互使用的通用接口。
结论
我们每个人心中都有一个梦想，那就是创造一个有生命的世界，一个宇宙。我们这些受过建筑师训练的人，也许在我们生活的中心有这样一种愿望:总有一天，在某个地方，以某种方式，我们将建造一座奇妙、美丽、令人惊叹的建筑，一个人们可以行走和梦想数百年的地方。-- 克里斯托弗亚历山大
Each one of us has, somewhere in his heart, the dream to make a living world, a universe. Those of us who have been trained as architects have this desire perhaps at the very center of our lives: that one day, somewhere, somehow, we shall build one building which is wonderful, beautiful, breathtaking, a place where people can walk and dream for centuries.-- Christopher Alexander
我们在互联网工程任务组开始努力定义现有的超文本传输​​协议（HTTP / 1.0）[ 19 ]并设计HTTP / 1.1 [ 42 ]和统一资源标识符（URI）新标准的扩展[ 21] ]，我认识到需要一个万维网应该如何工作的模型。这种在整个Web应用程序中进行交互的理想化模型（称为Representational State Transfer（REST）体系结构样式）成为现代Web体系结构的基础，提供了指导原则，通过该原理可以识别预先存在的体系结构中的缺陷和扩展在部署之前验证。
REST是一组协调的体系结构约束，旨在最大限度地减少延迟和网络通信，同时最大限度地提高组件实现的独立性和可伸缩性。这是通过在连接器语义上设置约束来实现的，其中其他样式专注于组件语义。REST支持交互的缓存和重用，组件的动态可替代性以及中介处理操作，从而满足Internet规模分布式超媒体系统的需求。
万维网可以说是世界上最大的分布式应用程序。了解Web底层的关键架构原则有助于解释其技术成功，并可能导致其他分布式应用程序的改进，特别是那些适合相同或类似交互方法的应用程序。REST贡献了现代Web软件体系结构背后的基本原理，以及如何在真实软件系统的设计和评估中系统地应用软件工程原理的重要教训。