1. 概述
Roy Fielding博士（见个人主页）是IETF发布的HTTP和URI协议的主要设计者。HTTP和URI是两个最为重要的Web基础技术架构协议，因此Fielding博士可谓是Web架构的奠基者之一。
除了学术上的卓越成就之外，Fielding博士还参与过很多开源软件的设计和开发工作。他是libwww-perl（世界上最早的HTTP开发库之一）的开发者，曾经负责Apache HTTP服务器中与HTTP、URI协议相关部分代码的开发。Fielding博士还指导过很多其他团队在HTTP客户端和服务器端软件方面的开发工作。
HTTP/1.1协议（RFC 2616）于1999年发布，加上于1998年发布的URI协议（RFC 2396），至此Web的基础技术架构已经完全确立。为了向世人详细说明Web基础技术架构背后的设计原则，Fielding在2000年撰写了自己的著名博士学位论文《Architectural Styles and the Design of Network-based Software Architectures》。这篇论文的中文版名为《架构风格与基于网络的软件架构设计》，可以从InfoQ中文站上下载：
这篇论文很不容易读懂，作为论文中文版的译者，笔者试图在这篇导读中为读者梳理出一个阅读的脉络。不过笔者还是希望读者能克服困难，亲自去读一下这篇论文，因为这篇论文实在是太精彩了。《论语》有很多评注版本，但是读者最好还是自己亲自读一下《论语》原作，免得上了朱熹之流歪嘴和尚的当。下面我们进入正题。
2. 论文导读
Fielding博士论文一共包括了绪论和6章正文的内容。绪论的内容就是对6章正文的总结，不需要多说，以下分别对6章正文的每一章进行导读。
2.1 第1章——软件架构
在第1章中，Fielding重新定义了一套研究软件架构的术语，讨论了每个术语定义的由来，并且将这些术语与相关研究进行比较。Fielding还对其他软件架构研究者的一些相关研究进行了点评。
这些软件架构术语包括：软件架构、架构元素、组件、连接器、数据、配置、架构属性、架构风格。以下是Fielding重新给出的术语定义：
软件架构是一个软件系统在其操作的某个阶段的运行时（run-time）元素的抽象。一个系统可能由很多层抽象和很多个操作阶段组成，每层抽象和操作阶段都有自己的软件架构。
软件架构由一些架构元素（组件、连接器和数据）的配置来定义，这些元素之间的关系受到约束，以获得想要得到的一组架构属性。
组件是软件指令和内部状态的一个抽象单元，通过其接口提供对数据的转换能力。
连接器是对组件之间的通讯、协调或合作进行仲裁的一种抽象机制。
数据是组件通过连接器接收或发送的信息元素。
配置是在系统的运行期间组件、连接器和数据之间的架构关系的结构。
软件架构的架构属性集合包括了对组件、连接器和数据的选择和排列所导致的所有属性。架构属性是由架构中的一组约束所导致的。
架构风格是一组相互协作的架构约束，这些约束限制了架构元素的角色和功能，以及在任何一个遵循该风格的架构中允许存在的元素之间的关系。
Fielding在将自己的术语定义与相关研究进行比较的过程中，对于一些相关研究提出了批评。例如：
“一些相关的研究完全不关注软件在运行时的特性，而只关注软件静态的源代码中的结构特性。”
Fielding将这些研究者的研究内容称作“软件结构”，他不认为这是严格意义上的“软件架构”。Fielding明确指出软件架构是软件在运行时的特性，他说：
“我们将软件架构和源代码结构分离开来，是为了更好地关注软件的运行时特性，这些特性不依赖于一个特定的组件实现。因此，尽管架构的设计和源代码结构的设计关系密切，它们其实是分离的设计活动。”
关注软件在运行时的特性，是Fielding的软件架构研究方法与其他研究者明显的不同之处。在对架构元素定义的讨论中，Fielding进一步解释了这个差别。按照他的说法，软件架构就好像是大楼的架构，而软件结构则好像是大楼的设计图纸。假如大楼的设计图纸丢失了，大楼并不会立即倒塌，因此不能将大楼的设计图纸看作是大楼的架构本身。同样地，不应该将画在纸面上的方框直线图（例如常见的ER图）看作是软件架构本身，那样会导致严重的纸上谈兵，即仅仅根据绘制在纸面上的方框直线图来研究软件架构，其实这些图形只代表了存在于软件源代码中的静态软件结构。
Fielding批评说：
“在这个过程中，软件架构被简化为通常在大多数非形式化的架构图表中能够看到的东西：方框（组件）和直线（连接器）。数据元素和其他很多真实软件架构的动态方面都被忽略了。这样的一个模型是不足以描述基于网络的软件架构的，因为对于基于网络的应用而言，数据元素在系统中的位置和移动常常是系统行为唯一至关重要的决定因素。”
（译者注：在UML中，除了静态的类图之外，还有时序图、状态图、活动图等等来表现各种动态的行为。但是在Fielding的博士论文研究期间，UML规范尚未完全稳定下来。）
在所有的软件架构研究者中，Fielding首次提出了软件的架构风格这样一个非常重要的概念，并且将软件架构风格当作是“一种用来对架构进行分类和定义它们的公共特征的机制。”
对于国内的软件架构研究者来说，架构风格是一个全新的概念。国内的软件架构研究者很少有人从架构风格这样高的抽象层次来思考软件的架构设计，几乎全部都是针对某种特定的架构来讨论。那么架构风格与特定架构是一种什么关系呢？
简单来说，架构风格与特定架构相比是更高层次的抽象。做一个不是很恰当的类比：假如将架构风格看作面向对象设计中的接口，那么特定的架构就是接口的实现类。例如：“分布式对象”是一种架构风格，而CORBA、DCOM、EJB、.NET Remoting都是分布式对象这种架构风格的架构实例。虽然它们四者之间存在着很多差别，但是它们其实属于同一种架构风格。
一种架构风格是由一组架构约束组成的，当将这组架构约束应用于某种特定的架构时，会产生出一些架构属性。这些架构约束和架构属性正是判断某种架构风格是否适合于一种特定运行环境的关键。
在讨论了上述这些软件架构术语之后，Fielding接下来讨论了模式和模式语言、架构视图，这两部分也很有趣。
在对模式和模式语言的讨论中，Fielding指出：
“如同软件的架构风格一样，软件模式的研究也偏离了其在建筑架构中的起源。”
他追根溯源地剖析了建筑学中模式语言的创造者Alexander大师(Jeffrey Charles Alexander)发明模式语言的本意。Fielding说：
“其实，Alexander的模式概念的核心并非是对于重复出现的架构元素的排列，而是发生在一个空间内重复出现的事件（人类的活动和情绪）的模式。Alexander还理解到：事件的模式不能脱离于发生这些事件的空间。”
架构视图代表的是对于特定架构的不同观察角度，Fielding说：
“观察一种架构，除了可从系统中的多个架构及组成这些架构的多种架构风格的角度之外，还有可能从很多其他的角度来观察。Perry和Wolf描述了三种重要的软件架构视图：处理、数据、连接。处理视图侧重于流过组件的数据流，以及组件之间连接的那些与数据相关的方面。数据视图侧重于处理的流程，而不是连接器。连接视图侧重于组件之间的关系和通信的状态。”
Fielding在后面论文的第5章中，正是使用了这三种视图来描述REST架构风格。不过在第5章中，三种视图的名称略有变化，处理（processing）视图变成了过程（process）视图、连接（connection）视图变成了连接器（connector）视图。
在第1章剩余的内容中，Fielding回顾了其他软件架构研究者的一些相关研究工作，并且对这些研究工作进行了点评。笔者注意到，这一部分并没有提到UML相关的研究工作。在笔者看来，尽管UML对于软件架构研究确实非常重要，但是UML其实只是一个沟通工具，UML的图形本身并不能教会设计者如何设计软件的架构（会画UML图 != 会设计复杂的软件架构）。另外UML的研究工作和Fielding的研究工作是并行的，Fielding可能并不了解UML同时取得的进展。