摘要: 从现代Web架构和由REST识别出的问题中，可以总结出很多通用的架构上的教训
正文:
架构上的教训
基于网络的API的优势
将现代Web与其他中间件相区分的是它使用HTTP作为一个基于网络的API，其实并非一向如此，早期的Web设计利用了一个程序库(CERN的libwww)作为所有的客户端和服务器端软件所使用的的单个协议实现库。CERN libwww提供了一个基于库的API来建造可互操作的Web组件
HTTP不是RPC
人们常常错误地将HTTP称为一种远程调用(RPC)机制，仅仅是因为它也包括了请求和响应。
RPC是调用远程机器上的一个过程，在RPC协议中，调用方识别出过程并且传递一组固定的参数，然后等待在使用相同接口返回的一个消息中提供的回答。Java的RMI(远程方法调用)就很类似，差异仅仅是将过程标识为一个对象、方法的组合，而不是一个简单的服务过程。
当然，将HTTP与RPC区分开的并不是上面的语法和特性，其重要的区别是：HTTP是请求被定向到使用一个有标准语义的通用接口的资源，中间组件几乎完全相同的方式来解释这些语义，结果就是使得一个应用能够支持转换的分层和独立于信息来源的间接层，这对于一个满足互联网规模、多个组织、无法控制的可伸缩性需求的信息系统来说是非常有用的；RPC的机制是根据语言的API来定义的，而不是根据基于网络应用的需求来定义的
HTTP不是一种传输协议
HTTP并非被设计为一种传输协议，它是一种移交协议
Web各组件都能理解HTTP语义，从而可以独自的完成HTTP的响应，而不必一定到达最终的源服务器，这也是为什么它是移交不是传输协议的原因
媒体类型的设计
REST有一个对架构风格来说不同寻常的方面，那就是它对于Web架构中数据元素的定义影响程度
应用状态
应用的开发者经常违背的就是应用状态和无状态交互架构约束。将应用状态放错地方而造成架构不匹配并不仅限于上篇文章提到的
Cookie，还有HTML中引入的frame，在一个子窗口中选择链接而导致的状态迁移与正常的状态迁移是无法区分的作者认为frame和cookie的失败之处在于，用户代理无法管理或解释它们所提供的间接应用状态。替代的设计是将这些信息放到一个主要的表述中，并且告知用户代理如何去管理这个存放了指定的资源领域的工作区
Java VS JavaScript
通过使用REST，我们能够知道为何一些媒体类型与其他类型相比在Web架构中得到了更加广泛的接受，甚至这些类型并未取得开发者偏爱的情况下(例如Java Applet对抗JavaScript)
作者认为JavaScript在Web上比Java更成功体现在可见的交互性影响较少、复杂性比较小、用户感知的延迟
总结
REST论文的阅读到此结束了，可以看出来REST主要是提供了一套指导原则，可以根据这些原则来识别架构中的缺陷，现代Web是REST架构风格的一个架构实例。在一个理想的世界里，软件系统的实现与它的设计有着精确的匹配，现代Web架构的一些功能确实完全符合它们在REST中的设计标准，例如通过URI标识资源，使用MediaTypes标识数据格式等
REST既贡献了现代Web软件架构背后的基础理论，也为我们上了重要的一课，展示了软件工程原则如何能够被系统地应用在一个真实的软件系统的设计与评估之中
接下来会去阅读网络协议与RestFul API最佳的设计等
