從去年開始我一直在翻譯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則明確翻譯爲“轉移”。