《REST实战》译者序
dlee
Web取得了巨大的成功，其原因是多方面的：技术层面、社会层面、经济层面、文化层面等等。早在十几年前，有一群人想要总结清楚Web取得巨大成功，技
术层面的原因究竟是什么？
经过深入细致的分析之后，他们将Web取得成功在技术层面的原因，总结为一种崭新的分布式应用架构风格（Architectural Style）——
REST（表述性状态转移）。简单来说，Web的架构风格就是REST，所有希望在Web生态系统中繁荣发展的技术，都应该符合REST这种架构风格的
要求。
事实上，HTTP 1.1规范正是基于REST架构风格的指导原理来设计的，其目标是实现符合REST风格的分布式应用架构。HTTP 1.1规范
（RFC 2616）在1999年6月正式发布。次年（2000年），HTTP 1.1规范的主要设计者Roy Fielding在他的博士论文
《Architectural Styles and the Design of Network-based Software
Architectures》（中文版名为《架构风格与基于网络的软件架构设计》）中，系统地阐述了REST这种架构风格的推导过程和详细理念。
架构风格这个术语，对于国内的软件开发者来说，感觉非常陌生。架构风格与某种具体的架构相比，是一个更加抽象的概念，它其实是一种研究和评价软件架构设
计的方法。我来做个类比：在建筑学中也存在有很多种类的架构风格，每一种架构风格会对建筑的具体样式（架构）产生很多约束。建造一座建筑，一定要考虑与
所处环境的架构风格相融合，而不是相冲突。试想一下，假如在苏州的拙政园（代表样式为小桥流水、移步换景的窗户，表达出天人合一的理念）旁边修造一座西
方哥特式（代表样式为直刺天空的尖顶，表达出人定胜天的理念）的大教堂，看起来将会是何等的突兀。如果在苏州园林周围修造了大量与该地架构风格完全冲突
的新式建筑，估计就不会有人有兴趣到苏州去游玩了。
大致了解了建筑学中的架构风格，我们再来看看计算机软件应用中的架构风格，特别是分布式应用的架构风格。
除了REST之外，另外两种常见的分布式应用架构风格包括：DO（分布式对象）、RPC（远程过程调用）。这两种架构风格在企业应用中得到了广泛的应
用，然而，Web架构的设计者们却有意避免采用这两种架构风格。主要的原因是运行Web应用的互联网环境，与运行企业应用的企业内网环境有很大的差别。
那么，互联网环境有哪些独有的特点呢？
1. 可伸缩性要求难以预测和无法控制：一个Web应用的并发访问量，是开发者难以预测和无法控制的。
2. 安全性要求难以预测和无法控制：一个Web应用所接受的请求格式，是开发者难以预测和无法控制的，有可能出现大量恶意构造的请求格式。
3. 松耦合至关重要：因为存在着大量异构的系统，必须要追求最大限度的松耦合。
4. 简单性至关重要：不可引入复杂的编程模型，必须降低开发者开发Web应用的门槛。
软件应用所处的运行环境会对其架构设计产生巨大影响。设计软件应用的架构，一定要深入考虑软件所处的运行环境。脱离开软件所处的运行环境，比较不同架构
之间的优劣是没有意义的。
REST这种架构风格，正是为面向互联网的Web应用量身定制的。它由一组架构约束组成：
1. 客户-服务器
2. 无状态
3. 缓存
4. 统一接口
5. 分层系统
6. 按需代码（可选）
这些架构约束正是互联网环境对于分布式应用架构设计所产生的外在约束。对于这些架构约束的详细描述，读者可以参考Fielding博士论文的中文版。
现在看来，REST在2000年那个时代，确实是超前于时代的。在那个时候，DO这种架构风格占据着绝对的统治地位。业界盛行着对于EJB和DCOM的
大肆炒作，而基于SOAP/WSDL的Web Services被普遍认为代表了分布式应用架构设计的未来，这几种架构无一例外都是DO风格的。另外由
于Fielding博士论文本身的学术性很强，在一线的Web开发者社区中并没有引起多大的反响。对于HTTP的设计意图存在着大量的误解，由此导致了
对于HTTP的大量低效率的误用。
这个情况持续一直到2005年Web 2.0的崛起。那个时候，DCOM、EJB、SOAP/WSDL这些DO风格的架构所存在的问题逐渐清晰。这些架
构因为难以满足互联网环境对分布式应用架构设计的约束，与Web自身的架构风格REST相冲突，很难融入到Web之中。所谓的“Web
Services”，其实除了将HTTP作为底层的传输协议外，跟（互联网环境中的）真正的Web没有什么关系。而真正的面向互联网的Web服务，不应
该采用DO或者RPC风格的架构。于是，Web开发者不约而同地将目光转向了REST，并且发起了一场运动，正本清源地理解Web自身的架构风格，以及
HTTP协议的真正设计意图。
这场运动受到了Ruby on Rails这个著名的Web开发框架（以下简称Rails）的大力推动。Rails的创造者David
Heinemeier Hansson
（DHH）在一篇主题演讲《Discovering a world of Resources on Rails》中，介绍了在Rails 1.2版
中对于REST开发的支持，并且将支持REST开发作为Rails未来发展的优先目标。虽然从理论上来说，任何支持HTTP协议的编程语言都可以做
REST开发，但是直到Rails大力支持REST开发之后，一线的Web开发者才真正接触到了REST开发。DHH在Web开发者社区中强大的营销能
力，无疑大力推动了REST开发的普及。
尽管如此，但是Rails所支持的REST开发将对资源的操作局限于CRUD（创建、获取、修改、删除）的语义（即，将对资源的CRUD操作映射到
GET/POST/PUT/DELETE四个HTTP方法），这其实是收窄了REST的适用范围。而且在Rails对于REST开发的支持中，并没有直
接支持超文本驱动（Hypertext Driven）的理念，而这是REST架构风格最核心的理念，也是REST风格的架构达到松耦合目标的根本原
因。可以这样说，Rails对于REST开发的支持方式，给Web开发者社区带来了很大的误导。其他编程语言的Web开发框架（例如Java语言的
Struts、Spring MVC等等）对于REST开发的支持，大多模仿了Rails的方式，这导致了一线的Web开发者误以为：REST开发就是
通过GET/POST/PUT/DELETE四个HTTP方法对资源执行CRUD操作。甚至还有很多仅仅使用了HTTP，而没有使用SOAP的Web服
务API，都自称是REST风格（RESTful）的API。对于什么才是真正的REST风格的误解是如此之多，而将REST作为一个便于营销的
buzzword的挂羊头卖狗肉者也是如此之多，以至于REST的创造者Fielding终于忍无可忍了。2008年10月Fielding写了一篇博
客，做出了一个非常明确的断言：REST APIs must be hypertext-driven（REST API必需是超文本驱动的）！
与2000年初次发表的那篇博士论文相比，Fielding的这篇博客在Web开发者社区中引起了巨大的反响。Web开发者发现自己有必要对REST做
更进一步的深入理解。超文本驱动这个理念变成了一个缩写词HATEOAS，这个缩写词来自于Fielding博士论文中的一句话：
hypermedia as the engine of application state（将超媒体作为应用状态的引擎）。支持HATEOAS的
REST开发框架在此后的几年中也逐渐出现。
如果按照Fielding对于REST风格API的这个严格的定义，那么包括Rails所支持的REST开发在内的绝大多数所谓的REST风格API，
都不能算是真正的REST风格API。不过大多数Web开发者更倾向于将REST风格API划分为不同的层级，O'Reilly《RESTful
Web Services》一书的作者Leonard Richardson为此专门设计了一个评价REST风格API所处层级的成熟度模型。
在Web开发者社区逐步深入实践REST开发的同时，REST这种为面向互联网的Web应用量身定制的架构风格，与其他来自Web的技术（HTTP/
HTML/CSS/JavaScript/Ajax/Atom）一起，逐渐渗透进入了企业应用的领域。一些企业应用，特别是SOA的架构师们发现，
REST架构风格所带来的可伸缩性、松耦合、简单性等等优点，对于实现SOA的目标具有非常大的价值。在Java企业应用领域，与基于SOAP/
WSDL的传统Web Services协议栈JAX-WS相对应，REST架构风格的JAX-RS协议栈正在逐渐成型。IBM/Oracle（包括
BEA+Sun）/Microsoft等大公司的企业应用产品，有很多都已经提供了REST风格的API。不过对于REST在企业应用领域的进展，我持
有谨慎乐观的态度。与REST风格在Web应用领域一枝独秀相比，在企业应用领域，REST更有可能是与DO、RPC风格的架构保持长期竞争的局面，它
们之间是相互补充，而不是相互取代的关系。
从以上对于历史的回顾中，我们看到，Web开发者理解REST架构风格的理论，并将其应用于开发实践，有一个由浅入深的的漫长过程。REST从最初用来
指导HTTP 1.1等Web标准的设计——到用来指导Web浏览器、Web服务器、HTTP代理服务器这些基础设施的开发——再到用来指导Web应用
的架构设计——最后进入企业应用领域，成为了SOA的重要实现技术。同时，Web开发者对于使用HTTP的最佳实践，也有一个由浅入深的过程。最终大家
认识到，HTTP并不是一种传输层的“传输协议”（在国内，HTTP长期以来被错误翻译为“超文本传输协议”。我曾试图以一己之力来纠正这个错误），而
是一种应用层的“转移协议”。HTTP有非常丰富的语义，它定义了一个操作服务器端资源的统一接口。而对于资源的操作，也不仅仅局限于CRUD操作的语
义，还可以通过在资源的表述中加入超链接，以实现超文本驱动的业务协议。
可喜的是，Fielding关于REST架构风格的这些设计思想，今天在实战层面已经开花结果，早已不再停留在理论层面。业界出现了大量支持REST的
开发框架、库，以及相关的图书。《REST实战》这本书是目前为止REST开发领域最为全面、最为深入的著作（没有之一）。想要了解REST开发的
What、Why、How（对于新知识的通常认知过程），《REST实战》这本书就是最佳的选择。本书的三位作者，对于分布式应用的架构设计和开发有着
极为丰富的经验，除了精通Web开发技术外，他们又都是SOA领域的专家。阅读本书是一次非常棒的体验之旅，常常会让人有击节叹赏的快感。在本书之前，
我还从未看到一本书能够将复杂的理论概念讲解的如此深入浅出，同时配合有大量令人信服的实战代码。与业界对于REST的认识过程一样，本书对于REST
的讲解也是由浅入深、循序渐进的。我曾经和本书的审校者余晟老师说：学习这本书的过程很像是修炼“乾坤大挪移”的过程，每一个后面的章都代表了功法中的
更高一层。悟性差的人，理解到CRUD式Web服务就满足了。而悟性好的人，可以彻底理解超文本驱动，甚至是与REST关系密切的语义网，最终达到
REST开发的最高境界。不过即使只修炼到了较低层次，读者仍然会发现自己对于Web应用的架构设计有了更加深入的理解，对于日常开发仍然会很有帮助
的。我在此郑重建议国内所有分布式应用的开发者们都应该仔细读一下这本书。这本书对于提升分布式应用架构设计的水平，会有非常大的帮助。
本书由李锟、俞黎敏、马钧、崔毅翻译，最终由李锟负责审校。工作于盛大创新院的余晟老师也协助我们做了很多章节的审校工作，指出了译文中的大量错误，对
于保证本书的翻译质量有非常大的帮助。在此我们对余晟老师的辛勤付出表示衷心的感谢！此外，我们还要感谢Jim Webber等三位作者写下了这本传世
的杰作，也感谢东南大学出版社给了我们翻译这本书的机会。
对于REST开发感兴趣，希望开展深入讨论的读者，欢迎加入我所创办的“REST实战讨论组”：http://groups.google.com/
group/rest_in_action ，也可以加入“REST实战讨论组”的QQ群，群号为81207617。
李锟
2011年8月6日 于上海
kacakong kacakong
--
您收到此邮件是因为您订阅了 Google 网上论坛的“REST实战”论坛。
要向此网上论坛发帖，请发送电子邮件至 rest_in...@googlegroups.com。
要取消订阅此网上论坛，请发送电子邮件至 rest_in_actio...@googlegroups.com。
若有更多问题，请通过 http://groups.google.com/group/rest_in_action?hl=zh-CN 访问此网上论坛。
Shawn XIAO
胡滨海
long hao
黄明
文采很好！
支持!
hu xiangwei
--
您收到此邮件是因为您订阅了 Google 网上论坛的“REST实战”论坛。
要向此网上论坛发帖，请发送电子邮件至 rest_in...@googlegroups.com。
要取消订阅此网上论坛，请发送电子邮件至 rest_in_actio...@googlegroups.com。
若有更多问题，请通过 http://groups.google.com/group/rest_in_action?hl=zh-CN 访问此网上论坛。
--
胡相伟
shi yi ying
张羽翼
dlee
上市时间推迟，东南大学出版社给出的解释是：7、8月是印刷厂的旺季，印刷厂安排不过来。
李锟
On Aug 15, 10:26 am, 张羽翼 <yes...@gmail.com> wrote:
> 什么时候上市呢～ 期待好久了～
>
> 在 2011年8月6日 下午8:39，dlee <dlee...@gmail.com>写道：
>