从去年开始我一直在翻译O'Relly的《RESTful Web Services Cookbook 》，翻译的过程有些纠结，导致整本书的进度比预期的要慢很多，但一切原因都不能影响翻译的质量，我依然坚持这样一个原则。再过一段时间这本书就能与读者见面了，放上译者序，小小庆祝一番。
有人说计算机搞的是科学，也有人说计算机搞的是工程，于是大学里的计算机系通常叫“计算机科学与工程系”。两种说法究竟孰对孰错，我们不去深究，但请允许我做一个也许不怎么恰当的对比：
?
- 1905年，Albert Einstein提出了具有划时代意义的相对论，100年过去了，绝大多数人只是知道世上有这么一个伟大的理论，真正理解它的人却寥寥无几。
- 2000年，Roy Fielding在他的博士论文【注1】中提出了“表述性状态转移”（REST），10年过去了，很多开发者都知道REST，但真的能把它说明白的同样没几个。
两者的境遇很相似，物理学家总数就不多，理解相对论的人少也还说得过去，可为什么说很多开发者都不理解REST呢？以Fielding博士设计的 HTTP协议为例，大家都把它当作一种传输协议，但HTTP其实是为REST而生的，它能够表达状态和状态转移，这就是它位于应用层而非传输层的原因，所 以说HTTP中的Transfer被翻译成“转移”更为恰当。
?
如果说是Rails让大家开始真正关注REST，那么开放平台的兴起则让REST越来越多地出现在舞台上。各种基于HTTP的服务都宣称自己是 REST风格的，曾经有段时间，不挂个REST的牌子，出门都不好意思和人打招呼，哪怕自己是挂羊头卖狗肉也得和REST扯上关系。最 后，Fielding博士非常失望，只能亲自撰写文章【注2】告诉大家――你们搞错了，我设计的REST并非如此。
?
那么，真正的REST服务究竟是怎么样的呢？如果您也曾经读过那篇论文，或者是尝试读过，一定会发现要读懂它真的得花一番功夫。有没有人可以用通俗 易懂的方式指导大家设计并实现REST服务呢？雅虎的资深架构师Subbu Allamaraju做到了，本书涉及了设计RESTful Web服务的方方面面，总结了他多年的设计经验，书中没有枯燥冗长的理论说明，而是通过大量生动的范例来说明那些最佳实践，“问题描述”、“解决方案”和 “问题讨论”这样的安排也让阅读更有针对性。无论您使用的是什么语言，都可以选择本书作为设计服务的参考，原因有两个――1、设计好的服务的原则是不随语 言而变化的；2、本书的范例全部都是HTTP报文，无论使用何种语言、何种框架，最终都会变成HTTP报文。因此，没有什么理由可以让我们拒绝它。
?
本书的翻译过程有些纠结，但收获也很多，至少让我对REST有了更清晰的认识。感谢李锟把本书介绍给了我，并建议我来主导全书的翻译，我们做了很多 深入的沟通，探讨了很多实际的问题【注3】。在我快要抓狂的时候，常可加入了进来，他为读者能早日见到本书做出了很多贡献。同样也要感谢唐力群与郑佰云之 前的协助，还有博文视点的多位编辑，正是有了这么多人的努力，才有了大家现在看到的这本书，希望它能给大家带来一些实实在在的帮助。如果您有什么意见或建 议，发现了书中翻译的错误，欢迎通过各种渠道告诉我们。
丁雪丰
2011年6月
?
注1：
论文标题为《Architectural Styles and the Design of Network-based Software Architectures》，http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm
。2007年，李锟等人将该论文翻译为中文发布于http://www.redsaga.com/opendoc/REST_cn.pdf
。
注2：
文章标题为《REST APIs must be hypertext-driven》，http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven
。
注3：
我们甚至还讨论过Hypertext Transfer
Protocol该如何翻译。李锟建议翻译为“超文本转移协议”，要纠正之前错误的认识，而我则认为对于约定俗成的名字应该保持原样，并加以说明。最后争
论不下，决定书中的Hypertext Transfer Protocol不做翻译，单独出现的transfer则明确翻译为“转移”。