Rest Notes-设计Web架构:问题与领悟

摘要: 本文介绍Web架构的需求,以及作者在对Web通信协议做设计评估遇到的问题,根据上篇文章的调查和分类获得的领悟推导出了开发某种架构风格的方法,用来改进现代Web架构的设计工作提供指导

正文:

设计Web架构:问题与领悟

Web应用领域的需求

Berners-Lee(Web之父)写到:“Web’s major goal was to be a shared information space
through which people and machines could communicate”,意思是Web的主要目的是旨在形成一种共享的信息空间(链接众多文档的广域的超媒体信息检索系统),人类和机器都可以通过它来进行沟通

这个系统最初期望的用户是分散在世界各地的、通过互联网连接的各个大学和政府的高能物理研究实验室。他们的机器是不同种类的终端、工作站、服务器和超级计算机的大杂烩,所以他们的操作系统和文件格式也是一个大杂烩。构建一个这样的系统所面临的挑战是为这些信息文档提供统一的接口,使得这些信息可以在众多的平台上进行交流通信,以及当新的设备接入到这个系统时,可以进行增量的部署。

低门槛

参与创建和构造信息是自愿的,因此采用“低门槛”策略是十分必要的。

选择超媒体作为用户界面是因为其简单性和通用性。

  1. 无论信息来源何处都能使用相同的界面进行呈现
  2. 链接的关系可以形成一个关系“网状结构”

对于创作者而言,超媒体的创作语言也必须是简单的,能够使用现有的编辑工具来进行创建,无论是否连接到互联网,都可以使用此超媒体格式来保存创作的内容。

对于应用开发者而言,简单性也是一个目标,因此所有的协议都被定义为文本格式,以方便对通信进行观察和测试。

可扩展性

简单性使得我们部署一个分布式系统的最初实现成为了可能,可扩展性使得我们避免了永远陷入已部署系统的局限之中。就像社会的变化一样,一个系统如果想要像Web那么长寿就必须要做好应对变化的准备

分布式超媒体

超媒体是由应用控制信息来定义的,这些信息内嵌在信息的表述之中。分布式超媒体系统允许在远程地点存储表达控制信息,因此分布式超媒体系统中的用户操作需要将大量的数据从其存储地移交到其使用地,所以Web的架构必须支持大粒度的数据移交。超媒体交互的可用性很容易影响到用户感知的性能(比如用户选择了一个链接,到链接的界面呈现之间的时间),因为Web的交互的信息是跨域整个互联网的,则Web的架构必须尽量的减少网络交互的次数以改善用户感知的性能。

互联网规模

Web旨在成为一个互联网规模的分布式超媒体系统,这意味着它的内涵远远不止仅仅是地理上的分布。互联网是跨越组织便捷互相连接的信息网络。信息服务的提供商必须能够有能力满足无法控制的可伸缩性和软件组件的独立部署两方面的要求

  • 可伸缩性

    无法控制的可伸缩性指的是架构元素可能会于其组织边界之外的元素进行通信,当它们遇到如下的情况时仍能正常运行:未曾预料到的负载、收到错误的数据或者恶意的数据等等

  • 独立部署

    多个组织边界也意味着系统应该可以应对新旧组件的共存,而不妨碍新组件使用它们的新功能。同时现有的架构元素在设计的时候需要考虑到以后会添加新功能,旧的实现也必须能够方便的识别出来,从而把这些遗留的行为封装起来,不会对新元素造成不利影响。对于Web这样的系统来说,强制要求架构中的所有组件都整齐划一的来部署是不现实的事情

问题

尽管为Web的成功而欢欣鼓舞,但互联网开发者社区开始担心Web使用的快速增长率,因为最早的HTTP0.9是一个非常简单的协议,是为单个请求响应设计的,新的站点越来越多的采用了图片作为网页的一部分,导致出现了不同的浏览模式。此时的Web架构已经无法满足这样的需求了,随后在IETF形成了三个工作小组HTTP,URI和HTML。这些工作组的主要任务是定义现有架构性通信的子集(早期Web中普遍的一致的实现),然后指定一组规范来解决这些问题。这些工作带来的挑战是如何把一组新功能引入到一个已经被广泛部署的系统中;以及如何确保新功能的引入不会对那些使得Web成功的架构属性带来不利的影响甚至是毁灭性的影响

解决之道

  1. 识别出一组存在于早期Web架构(HTTP1.0和HTTP1.1之前)中的架构约束,这些架构约束负责产生出所期待的架构属性
  2. 识别出在互联网规模的分布式超媒体系统中所期待的架构属性,然后选择额外的会产生那些架构属性的架构风格,将它们与早期的Web架构中的约束相结合,形成一种新的风格
  3. 使用新的架构风格作为指导,对修改和扩展Web架构的提议进行评估,看其是否存在冲突,如果存在冲突则表明这个提议违反了一个或多个Web背后的设计原则

上面的1、2、3实际上是一种无顺序的、迭代的方式来应用的

修正后的协议规范是根据”新的架构风格“的指导来编写的,最后通过修订后规范,开发实现它,然后进行部署。这些解决之道是源自于Fielding博士直接参与了Apache Http服务器的项目和libwww-perl客户端库,以及为网景的Navigator、Lynx和微软的IE的开发者提供建议得到的经验

下篇文章就要介绍上面的“新的架构风格”(REST)推导过程