RESTful Web Services 前言(翻译)

      最近在研究服务计算，忽然看到这本书，发现写的非常好。尤其是翻译了前沿之后，再结合Srinath Perera和Ajith Ranabahu写的关于Axis的消息机制http://www.matrix.org.cn/resource/article/43/43723_Apache_Axis2.html和对于Sanjiva Weerawarana访谈：揭秘REST/WS-*http://www.infoq.com/cn/articles/sanjiva-rest-myths，感觉果然不同了。这对于我们对于服务的理解有了很大的帮助。

     下面是对于前言的翻译，算是对本书的概览，2008年初这本书的中文版就要出了，当时候一定去买一本，觉得光看前言就觉得很有吸引力了。

    ps:本人这英语比较差，有些话翻译不出来，就胡乱翻译的，请大家指正，不过给点面子~~翻译出来就是为了自己看着方便，也给和我差不多的人一些帮助。

   ps2：Javaeye的文本格式太难调了，就这样吧
     

RESTful Web Services
 
Leonard Ricbardson&Sam Ruby
Foreword by David Hernemeier Hansson
 
Preface
前言
We wrote this book to tell you about an amazing new technology. It’s here, it’s hot,
and it promises to radically change the way we write distributed systems. We’re talking about the World Wide Web.
 
我们写这样一本书来告诉你一项令人吃惊的新技术。它就在这，它很火，而且它承诺快速改变我们编写分布式系统的方式。我们正在讨论的是World Wide Web。
 
Okay, it’s not a new technology. It’s not as hot as it used to be, and from a technical
standpoint it’s not incredibly amazing. But everything else is true. In 10 years the Web has changed the way we live, but it’s got more change left to give. The Web is a simple,ubiquitous, yet overlooked platform for distributed programming. The goal of this book is to pull out that change and send it off into the world.
 
好吧，那不是一项新技术。它也不像昔日那么火，从技术角度来看它也不是难以置信的令人惊奇。但其他方面是真的。在10年内，我们已经改变了我们生活的方式，但是它留给我们更多可以获得的改变。Web是一个简单的，普遍存在的，也是被忽视的，为分布式编程提供的平台。这本书的目标是推出这个改变并把它发布到世界。
 
It may seem strange to claim that the Web’s potential for distributed programming has been overlooked. After all, this book competes for shelf space with any number of other books about web services. The problem is, most of today’s “web services” have nothing to do with the Web. In opposition to the Web’s simplicity, they espouse a heavyweight architecture for distributed object access, similar to COM or CORBA. Today’s “web service” architectures reinvent or ignore every feature that makes the Web successful.
 
辩解Web对于分布式编程的潜力被忽视看上去有些奇怪。毕竟，这本书在和其他关于web services的书在书架上抢地盘。问题是，今天大部分的“web services”和web没什么关系。反对Web的简单性，他们支持一个重型的为像COM或者CORBA那样的分布式对象访问的架构。今天的“web service”架构重复造轮子或者忽视每一个使Web成功的特性。
 
It doesn’t have to be that way. We know the technologies behind the Web can drive useful remote services, because those services exist and we use them every day. We know such services can scale to enormous size, because they already do. Consider the Google search engine. What is it but a remote service for querying a massive database and getting back a formatted response? We don’t normally think of web sites as “services,” because that’s programming talk and a web site’s ultimate client is a human, but services are what they are.
 
 它不得不是那个样子。我们知道Web下的技术能够驱动有用的远程服务，因为这些服务存在并且我们每天都使用它们。我们知道这些服务可以扩展到庞大的规模，因为他们已经这样做了。考虑Google搜索引擎。它不是一个为了搜索一个庞大的数据库并获得格式化响应的远程服务还是什么？我们通常不认为web sites是一个“服务”，因为那是编程话题，一个web站点的终端客户是一个人，但是服务是它们本身。
 
Every web application—every web site—is a service. You can harness this power for programmable applications if you work with the Web instead of against it, if you don’t bury its unique power under layers of abstraction. It’s time to put the “web” back into “web services.”
 
每个web应用——每一个web站点——是一个服务。你可以利用这种能力在可编程的应用上，如果你和Web和睦相处而不是抵触它，如果你不把这种独一无二的能力隐藏在抽象层次之下。是时候把“web”还原成“web services”了。
 
The features that make a web site easy for a web surfer to use also make a web service
API easy for a programmer to use. To find the principles underlying the design of these services, we can just translate the principles for human-readable web sites into terms that make sense when the surfers are computer programs.
 
使web站点对于一个web冲浪者而言更容易使用的特性也使web service API对于一个程序员而言容易使用。为发现这些服务的设计的内在原则，我们可以只将这些人类易读的web站点的原则转化成当访问者是计算机程序时有意义条目。
 
That’s what we do in this book. Our goal throughout is to show the power (and, where appropriate, the limitations) of the basic web technologies: the HTTP application protocol, the URI naming standard, and the XML markup language. Our topic is the set of principles underlying the Web: Representational State Transfer, or REST. For the first time, we set down best practices for “RESTful” web services. We cut through the confusion and guesswork, replacing folklore and implicit knowledge with concrete advice.
 
这就是我们在本书中所要做的。我们的目标始终是展示基本web技术的力量（和在哪里适用，以及局限性）：HTTP应用协议，URI命名标准，和XML标记语言。我们的主题是一系列Web内在原则：表现状态转换，或者REST。第一次，我们记录下这些“RESTful”web services原则。我们带着具体的忠告穿过混乱和猜测，替换民间传说和盲从的知识。
 
We introduce the Resource-Oriented Architecture (ROA), a commonsense set of rules
for designing RESTful web services. We also show you the view from the client side:
how you can write programs to consume RESTful services. Our examples include realworld RESTful services like Amazon’s Simple Storage Service (S3), the various incarnations of the Atom Publishing Protocol, and Google Maps. We also take popular
services that fall short of RESTfulness, like the del.icio.us social bookmarking API, and rehabilitate them.
 
我们介绍面向资源的架构（ROA），一组设计RESTful风格的web service的常识性的原则。我们也会向你展示来自客户端方面的视角：你可以如何编写程序来使用RESTful风格的services。我们的例子包括真实世界的RESTful服务像Amazon的简单存储服务（S3），不同种类的Atom发布协议的具体化，和Google Maps。我们也提供一些流行的不符合RESTful风格的服务，比如del.icio.us社会化书签API，并把它复原为RESTful风格。
 
The Web Is Simple
Web是简单的
Why are we so obsessed with the Web that we think it can do everything? Perhaps we
are delusional, the victims of hype. The web is certainly the most-hyped part of the
Internet, despite the fact that HTTP is not the most popular Internet protocol.
为什么我们如此着迷Web能做我们想要的一切？或许我们是错觉，骗局的牺牲品。Web的确就是Internet的最大骗局的一部分，尽管HTTP不是最流行的Internet协议的事实。
 
Depending on who’s measuring, the bulk of the world’s Internet traffic comes from email (thanks to spam) or BitTorrent (thanks to copyright infringement). If the Internet were to disappear tomorrow, email is the application people would miss the most. So why the Web? What makes HTTP, a protocol designed to schlep project notes around a physics lab, also suited for distributed Internet applications?
Actually, to say that HTTP was designed for anything is to pay it a pretty big compliment.
依赖于某人的测量，大多数的世界上的Internet交通来自于email（感谢垃圾邮件）或者BT（感谢盗版）。如果Internet明天消失，email是人们最想念的应用。所以为什么Web？什么使得HTTP，一个被设计成最大的跨越一个物理实验室的搬运项目记录的协议，也可以适用于分布式的Internet应用？事实上，说HTTP被设计成一切是最大的赞扬。
 
HTTP and HTML have been called “the Whoopee Cushion and Joy Buzzer of
Internet protocols, only comprehensible as elaborate practical jokes”—and that’s by
someone who likes them.* The first version of HTTP sure looked like a joke. Here’s a sample interaction between client and server:
 
HTTP和HTML被称为“Internet协议的Whoopee Cushion和Joy Buzzer，只是利于理解为精心制作的恶作剧笑话”——一些像她们那样的人说的。HTTP的一个版本的确看上去像个笑话。这是一个简单的客户端和服务器之间的交互：
Client request Server response
GET/hello.txt Hello, world!

* Clay Shirky, “In Praise of Evolvable Systems” (http://www.shirky.com/writings/evolve.html)
 
That’s it. You connected to the server, gave it the path to a document, and then the
server sent you the contents of that document. You could do little else with HTTP 0.9.
It looked like a featureless rip-off of more sophisticated file transfer protocols like FTP.
 
就是这样。你连接到服务器，给它一个访问文档的路径，然后服务器发送给你文档的内容。你能够用HTTP0.9做点别的。看起来像一个没什么特色的更资深的像FTP那样的文件传输协议的模仿者。
 
This is, surprisingly, a big part of the answer. With tongue only slightly in cheek we
can say that HTTP is uniquely well suited to distributed Internet applications because
it has no features to speak of. You tell it what you want, and it gives it to you. In a twist straight out of a kung-fu movie,  HTTP’s weakness is its strength, its simplicity its power.
 
令人惊讶的，这是答案的一大部分。我们厚着脸皮说HTTP是唯一非常适合分布式Internet应用的，因为它没有任何特点可言。你告诉它你想要的，它就把它给你。在曲折坦白的中国功夫电影里，HTTP的缺点是它的实力，它的简单，它的能力。
 
In that first version of HTTP, cleverly disguised as a lack of features, we can see addressability and statelessness: the two basic design decisions that made HTTP an improvement on its rivals, and that keep it scalable up to today’s mega-sites. Many of the features lacking in HTTP 0.9 have since turned out to be unnecessary or counterproductive.
 
HTTP的第一个版本，聪明的伪装成一个缺乏的特性，我们可以看到寻址能力和无状态性：两个基本的设计决策使得HTTP成为一个对于它的竞争对手的改进，保持它的可扩展性直到今天的百万级站点。许多在HTTP0.9种缺失的特性后来都成为不必要的或者反生产力的了。
 
Adding them back actually cripples the Web. Most of the rest were implemented in the 1.0 and 1.1 revisions of the protocol. The other two technologies essential to the success of the Web, URIs and HTML (and, later, XML), are also simple in important senses.
 
加上它们实际削弱了Web。大多数余下的是在协议的1.0和1.1 版本中被实现。其他两项对于Web而言本质上是成功的技术，URI和HTML（和稍后的XML）在重要的感觉上也是简单的。
 
Obviously, these “simple” technologies are powerful enough to give us the Web and
the applications we use on it. In this book we go further, and claim that the World
Wide Web is a simple and flexible environment for distributed programming. We also
claim to know the reason for this: that there is no essential difference between the
human web designed for our own use, and the “programmable web” designed for consumption by software programs. We say: if the Web is good enough for humans, it’s good enough for robots. We just need to make some allowances. Computer programs are good at building and parsing complex data structures, but they’re not as flexible as humans when it comes to interpreting documents.
 
显而易见，这些简单的技术是足够强大给我Web和我们在其上使用的应用程序。在本书中，我们走的更远，主张World Wide Web是一个简单的和灵活的分布式编程环境。我们也主张知道这个的原因：在被设计为我们使用的人类的web和为软件程序消费而设计的“可编程web”没有本质区别。我们说：如果Web对人而言是足够好的，那么它对于机器人而言也是足够好的。我们只是需要留有余地。计算机程序擅长构架和解析复杂的数据结构，但是当他们遇到解释型的文档，其不能像人一样灵活。
Big Web Services Are Not Simple
Big Web Services不是简单的
There are a number of protocols and standards, mostly built on top of HTTP, designed
for building Web Services (note the capitalization). These standards are collectively
called the WS-* stack. They include WS-Notification, WS-Security, WSDL, and SOAP.
 
有一定数量的协议和标准，构建在HTTP的顶端，为了Web Services而设计（注意大写）。这些标准共同被称为WS-*堆栈。他们包括WS-Notification, WS-Security, WSDL, 和 SOAP.
 
Throughout this book we give the name “Big Web Services” to this collection of technologies as a fairly gentle term of disparagement.
 
本书中，我们给这组技术一个名字作为一个蔑视的相当文雅的术语——Big Web Services。
 
This book does not cover these standards in any great detail. We believe you can implement web services without implementing Big Web Services: that the Web should
be all the service you need. We believe the Web’s basic technologies are good enough
to be considered the default platform for distributed services.
 
这本书不覆盖这些标准的细枝末节。我们相信你可以实现web services而不实现Big Web Services：Web应该是你需要的所有服务。我们相信Web的基本技术是非常足够的来考虑分布式服务的默认平台。
 
Some of the WS-* standards (such as SOAP) can be used in ways compatible with REST and our Resource-Oriented Architecture. In practice, though, they’re used to implement Remote Procedure Call applications over HTTP. Sometimes an RPC style
is appropriate, and sometimes other needs take precedence over the virtues of the Web.
 
一些WS-*标准（如SOAP）可以以某种方式混合REST和我们的面向资源架构使用。在实践中，虽然我们习惯于通过HTTP实现远程过程调用应用。一些时候RPC风格是合适的，一些时候其他的需要优先于Web的优点。
 
This is fine.
 
这很好。
 
What we don’t like is needless complexity. Too often a programmer or a company
brings in Big Web Services for a job that plain old HTTP could handle just fine. The
effect is that HTTP is reduced to a transport protocol for an enormous XML payload
that explains what’s “really” going on. The resulting service is far too complex, impossible to debug, and won’t work unless your clients have the exact same setup as you do.
 
我们不喜欢的是毫无必要的复杂性。太多的开发者或者公司使用Big Web Services来完成普通HTTP可以做的很好的工作。结果是HTTP被迫成为一个庞大的解释什么“真的”在运行的XML有效负载的传输协议。结果服务超级复杂，无法调试，除非你的客户端有了严格相同的安装否则不能工作。
 
Big Web Services do have one advantage: modern tools can create a web service from
your code with a single click, especially if you’re developing in Java or C#. If you’re using these tools to generate RPC-style web services with the WS-* stack, it probably doesn’t matter to you that a RESTful web service would be much simpler. The tools hide all the complexity, so who cares? Bandwidth and CPU are cheap.
 
Big Web Services有一个优点：现代的工具可以创造来自于你使用一个单独的click编写的web service，尤其如果你使用Java或C#开发。如果你正在使用这些工具生成RPC风格的web services使用WS-*堆栈，RESTful风格的web service将更加容易对你无所谓。这些工具隐藏了所有复杂性，所以谁在乎？带宽和CPU是廉价的。
 
This attitude works when you’re working in a homogeneous group, providing services behind a firewall for other groups like yours. If your group has enough political clout, you may be able to get people to play your way outside the firewall. But if you want your service to grow to Internet scale, you’ll have to handle clients you never planned for, using custom-built software stacks to do things to your service you never imagined were possible. Your users will want to integrate your service with other services you’ve never heard of. Sound difficult? This already happens on the Web every day.
 
这种态度在起作用，当你正工作在一个相似的组织，在防火墙后为另外一个像你们一样的组织提供服务。如果你的团队有足够的政治影响，你可能能够在防火墙以外按照你的方式来做。但是如果你想让你的服务发展到Internet范围，你将不得不操纵你从来没有考虑的客户端，使用个性化定制的软件堆栈来做你从来都没想过的服务是可能的。你们的用户将想要把你的服务和其他人的你从未听说过的服务整合在一起。听起来很难？不过这每天都发生在Web上。
 
Abstractions are never perfect. Every new layer creates failure points, interoperability
hassles, and scalability problems. New tools can hide complexity, but they can’t justify it—and they always add it. Getting a service to work with the Web as a whole means paying attention to adaptability, scalability, and maintainability. Simplicity—that despised virtue of HTTP 0.9—is a prerequisite for all three. The more complex the system, the more difficult it is to fix when something goes wrong.
 
提取从来都不是完美的。每个新的层次创造失败的观点，互操作性的争论，和可测量性的问题。新的工具能够掩盖复杂性，但是他们不能证明它是正当的——而且他们总是加上它。获得一个服务去把Web当成一个整体一起工作意味着关注适应性，可测量性，和可维护性。简单——轻视HTTP0.9的优点——是以上三点的先决条件。有越多复杂的系统，当它们出了问题时就越难修补。
 
If you provide RESTful web services, you can spend your complexity on additional features, or on making multiple services interact. Success in providing services also
means being part of the Web instead of just “on” the Web: making your information
available under the same rules that govern well-designed web sites. The closer you are
to the basic web protocols, the easier this is.
 
如果你提供RESTful风格的web services，你可以把复杂性用于一个特性，或者用于使多样的服务交互使用。成功的提高服务也意味着作为Web的一部分替代刚好“在”Web上：使你的信息在统治设计优良的web站点的相同的规则之下有效。你越关注基本的web协议，这将越容易。
The Story of the REST
REST的故事
REST is simple, but it’s well defined and not an excuse for implementing web services as half-assed web sites because “they’re the same.” Unfortunately, until now the main REST reference was chapter five of Roy Fielding’s 2000 Ph.D. dissertation, which is a good read for a Ph.D. dissertation, but leaves most of the real-world questions unanswered. That’s because it presents REST not as an architecture but as a way of judging architectures. The term “RESTful” is like the term “object-oriented.” A language, a framework, or an application may be designed in an object-oriented way, but that doesn’t make its architecture the object-oriented architecture.
 
REST是简单的，但是它是定义良好的，不是为了实施web services作为半吊子web站点的理由，因为“他们是相同的”。不幸的是，直到现在主要的REST参考文献是Roy Fielding的2000年的博士论文的第五章，对于一篇博士论文而言是很好的读物，不过失去了大多数真实世界的问题的回答。那是因为它介绍REST没作为一个体系结构而是作为审查架构的方式。术语“RESTful”像是术语“面向对象”。一种语言，一个框架，或者是一个应用可以以面向对象的方式设计，但是不能使它的架构成为面向对象的架构。
 
Even in object-oriented languages like C++ and Ruby, it’s possible to write programs
that are not truly object-oriented. HTTP in the abstract does very well on the criteria
of REST. (It ought to, since Fielding co-wrote the HTTP standard and wrote his dissertation to describe the architecture of the Web.) But real web sites, web applications,and web services often betray the principles of REST. How can you be sure you’re correctly applying the principles to the problem of designing a specific web service?
 
      甚至如C++和Ruby那样的面向对象语言，也可以写出非面向对象的程序。HTTP在理论上非常满足REST标准。（它应该是，因为Fielding参与编写了HTTP标准并且撰写了他的论文阐述Web架构。）但是真正的web站点，web应用和web服务经常违反REST规则。你如何能确定你是正确应用了准则到设计一个明确的web service的问题？
 
Most other sources of information on REST are informal: mailing lists, wikis, and
weblogs (I list some of the best in Appendix A). Up to now, REST’s best practices have been a matter of folklore. What’s needed is a concrete architecture based on the REST meta-architecture: a set of simple guidelines for implementing typical services that fulfill the potential of the Web. We present one such architecture in this book as the Resource-Oriented Architecture (see Chapter 4). It’s certainly not the only possible high-level RESTful architecture, but we think it’s a good one for designing web services that are easy for clients to use.
 
其他大部分REST信息资源是非正式的：邮件列表，wiki，和blog。到现在，REST的最佳时间大概还是民间传说。需要的是一个基于REST元架构的具体架构：一组简单的实施典型的满足Web潜能的服务的指导。我们在本书介绍了这样一个作为ROA的架构，它的确不是唯一可能的高层RESTful风格架构，但是我们认为它对于设计易于客户端使用的web services是很好的。
 
We wrote the ROA to bring the best practices of web service design out of the realm
of folklore. What we’ve written is a suggested baseline. If you’ve tried to figure out
REST in the past, we hope our architecture gives you confidence that what you’re doing is “really” REST. We also hope the ROA will help the community as a whole make faster progress in coming up with and codifying best practices. We want to make it easy for programmers to create distributed web applications that are elegant, that do the job they’re designed for, and that participate in the Web instead of merely living on top of it.
 
我们编写ROA来提供脱离民间传说的web service设计的最佳实践。我们已经编写的内容是建议的基线。如果在过去你试图领会REST，我们希望我们的架构能给你信心，你做的是“真正的”REST。我们也希望ROA可以帮助社区总体上加快进程拿出最佳实践并且汇编成集。我们想要使开发者容易地创建优雅的分布式web应用，使按照他们的设计工作，并参与到Web中而不是仅仅生活在其顶部。
 
We know, however, that it’s not enough to have all these technical facts at your disposal. We’ve both worked in organizations where major architectural decisions didn’t go our way. You can’t succeed with a RESTful architecture if you never get a chance to use it. In addition to the technical know-how, we must give you the vocabulary to argue for RESTful solutions. We’ve positioned the ROA as a simple alternative to the RPC-style architecture used by today’s SOAP+WSDL services. The RPC architecture exposes internal algorithms through a complex programming-language-like interface that’s different for every service. The ROA exposes internal data through a simple document-processing interface that’s always the same. In Chapter 10, we compare the two architectures and show how to argue for the ROA.
 
然而我们知道，拥有所有这些技术因素在你的安排中是不够的。我们俩工作的研究架构决策的组织并不按照我们的方式。如果你从来不给一个机会去使用它，你不可能因为RESTful而成功。除了技术上的专门知识之外，我们必须给你赞成RESTful解决方案的词典。我们将ROA定位为一种相对于今天使用SOAP+WSDL的服务的RPC风格的架构而言是一个简单的架构。
RPC架构通过一个复杂的、对于每个服务而言是不同的、类似于编程语言的接口暴露内部算法。ROA通过一个简单的、对于每个服务而言是相同的、文档处理接口暴露内部数据。
          在第10章中，我们比较了两种架构和展现了如何证明ROA是好的。
Reuniting the Webs
使Web重新组合
Programmers have been using web sites as web services for years—unofficially, of
course. It’s difficult for a computer to understand web pages designed for human
consumption, but that’s never stopped hackers from fetching pages with automated
clients and screen-scraping the interesting bits. Over time, this drive was sublimated
into programmer-friendly technologies for exposing a web site’s functionality in officially sanctioned ways—RSS, XML-RPC, and SOAP. These technologies formed a programmable web, one that extended the human web for the convenience of software programs.
 
程序员已经把Web站点作为web services使用很多年了——当然是非正式的。一个计算机去理解为人使用而设计的web网页是困难的，但是hacker们从来都没有停止使用自动化的客户端抓取网页和屏幕敲掉有趣的字节。随着时间的推移，这些驱动被提升为对于程序员而言友好的技术，这些技术允许以通过正式的被认可的方式暴露网站的功能——RSS，XML-RPC和SOAP。这些技术形成了一个可编程的web，一个将人的web扩展成为方便软件开发的web。
 
Our ultimate goal in this book is to reunite the programmable web with the human
web. We envision a single interconnected network: a World Wide Web that runs on
one set of servers, uses one set of protocols, and obeys one set of design principles. A
network that you can use whether you’re serving data to human beings or computer
programs.
 
我们在本书中的终极目标是将可编程的web和人的web重新结合起来。我们设想了一个单独的互相连接的网络：一个World Wide Web跑在一个组服务器上，使用一组协议，服从一组设计原则。一个你可以使用的网络无论你把数据给人还是给计算机程序。
 
The Internet and the Web did not have to exist. They come to us courtesy of misallocated defense money, skunkworks engineering projects, worse-is-better engineering practices, big science, naive liberal idealism, cranky libertarian politics, technofetishism,and the sweat and capital of programmers and investors who thought they’d found an easy way to strike it rich.
 
Internet和Web不是不得不存在。它们慷慨的给我们带来了，被错误分配的国防资金，欺骗工程项目，更坏的就是更好的工程实践，重要的科学，天真的自由主义理想主义，人性的自由主义政策，技术盲目崇拜，认为他们发现了一条容易的致富之路的程序员和投资者的汗水和资金。
 
The result is, amazingly, a simple, open (for now), almost universal platform for networked applications. This platform contains much of human knowledge and supports most fields of human endeavor. We think it’s time to seriously start applying its rules to distributed programming, to open up that information and those processes to automatic clients. If you agree, this book will show you to do it.
 
结果是，令人惊讶的，一个对于网络应用而言是简单的，开放的（对于现在），几乎是通用的平台。这个平台包含了众多人类的知识，并且支持大多数人类努力的领域。我们认为是时候认真地开始将它的规则应用于分布式编成，开放那些信息和过程给自动化的客户端。如果你认同，这本书将指导你做这些。
What’s in This Book?
这本书写了什么？
In this book we focus on practical issues: how to design and implement RESTful web
services, and clients for those services. Our secondary focus is on theory: what it means to be RESTful, and why web services should be more RESTful instead of less. We don’t cover everything, but we try to hit today’s big topics, and because this is the first book of its kind, we return to the core issue—how to design a RESTful service—over and over again.
 
在本书中，我们关注实际问题：如何设计和实施RESTful风格的web services，和使用这些服务的客户端。我们的第二个关注点是理论：它意味着RESTful是什么，和为什么web services应该更多RESTful风格而非更少。我们不涉及所有问题，但是我们试图触及当今最大的话题，因为这是这个方面的第一本书，我们一次又一次回到核心问题——如何设计一个RESTful风格的service。
 
The first three chapters introduce web services from the client’s perspective and show
what’s special about RESTful services.
 
前面三章从客户端的角度介绍web services，并且展示RESTful风格的services的特别之处。
Chapter 1, The Programmable Web and Its Inhabitants
第1章，可编程的Web和它的居民
In this chapter we introduce web services in general: programs that go over the
Web and ask a foreign server to provide data or run an algorithm. We demonstrate
the three common web service architectures: RESTful, RPC-style, and REST-RPC
hybrid. It shows sample HTTP requests and responses for each architecture, along
with typical client code.
 
在本章中，我们概括介绍web services：跨Web并且要求外部服务器提供数据或运行一个算法的程序。我们示范了三个普通的web service架构：RESTful，PRC风格和REST-RPC混合型。它展示了为每种架构和传统客户端代码的HTTP 请求和响应所举的例子。
Chapter 2, Writing Web Service Clients
第2章，编写Web Service客户端
In this chapter we show you how to write clients for existing web services, using
an HTTP library and an XML parser. We introduce a popular REST-RPC service
(the web service for the social bookmarking site del.icio.us) and demonstrate clients
written in Ruby, Python, Java, C#, and PHP. We also give technology recommendations for several other languages, without actually showing code.
JavaScript and Ajax are covered separately in Chapter 11.
 
在本章中，我们为您展示了如何为已有的web services编写客户端，使用一个HTTP库和一个XML解析器。我们介绍一个流行的REST-RPC服务（这个web service用于社会化书签站点del.icio.us），并且示范用Ruby，Python，Java，C#和PHP写成的客户端。我们也对于许多其他语言给出建议，而不是展示代码。
JavaScipt和Ajax将在第11章被单独讲述。
Chapter 3, What Makes RESTful Services Differen t?
第3章，什么使RESTful看起来不同？
We take the lessons of Chapter 2 and apply them to a purely RESTful service:
Amazon’s Simple Storage Service (S3). While building an S3 client we illustrate
some important principles of REST: resources, representations, and the uniform
interface.
 
我们利用第2章的课程，来将它应用于一个纯的RESTful风格的service：Amazon的简单存储服务（S3）。当构建一个S3客户端时我们举例说明一些重要的REST资源：资源，表现和统一接口。
 
The next six chapters form the core of the book. They focus on designing and implementing your own RESTful services.
 
接下来的六章是本书的核心部分。他们关注设计和实现你的RESTful风格的services。
 
Chapter 4, The Resource-Oriented Architecture
第4章，面向资源架构
A formal introduction to REST, not in its abstract form but in the context of a
specific architecture for web services. Our architecture is based on four important
REST concepts: resources, their names, their representations, and the links between
them. Its services should be judged by four RESTful properties: addressability,
statelessness, connectedness, and the uniform interface.
 
一份对于REST的正式介绍，不是它的抽象形式，而是一个用于web services的特定架构的内容。我们的架构基于四个重要的REST概念：资源，它们的名字，它们的表现，和两者之间的链接。它的服务应该是被四个RESTful的属性判定的：寻址能力，无状态性，连通性，和统一接口。
 
Chapter 5, Designing Read-Only Resource-Oriented Services
第5章，设计只读的面向资源服务
We present a procedure for turning an idea or a set of requirements into a set of
RESTful resources. These resources are read-only: clients can get data from your
service but they can’t send any data of their own. We illustrate the procedure by
designing a web service for serving navigable maps, inspired by the Google Maps
web application.
 
我们展示了一个将一个观点或者一组需求转换到一组RESTful资源的程序。这些资源是只读的：客户端可以从你的服务获得数据，但是不能发送他们自己的任何数据。我们举例说明用来设计一个服务于导航地图的web service的过程，灵感来自于Google Maps web应用。
Chapter 6, Designing Read/Write Resource-Oriented Services
第6章，设计可读/写的面向资源的服务
We extend the procedure from the previous chapter so that clients can create,
modify, and delete resources. We demonstrate by adding two new kinds of resource
to the map service: user accounts and user-defined places.
 
我们扩展了前面章节的程序，以使客户端可以创建，修改和删除资源。我们通过增加两个新的类型的资源到map服务中举例说明：用户帐户和用户定义的区域。
Chapter 7, A Service Implementation
第7章，一个服务的实现
We remodel an RPC-style service (the del.icio.us REST-RPC hybrid we wrote clients
for back in Chapter 2) as a purely RESTful service. Then we implement that
service as a Ruby on Rails application. Fun for the whole family!
 
我们重新建模一个RPC风格的服务（在第2章中我们为了后面编写的客户端del.icio.us REST-RPC混合体）作为纯的RESTful服务。然后我们实现那个service作为Ruby on Rails应用。全家其乐融融！
Chapter 8, REST and ROA Best Practices
第8章，REST和ROA最佳实践
In this chapter we collect our earlier suggestions for service design into one place,
and add new suggestions. We show how standard features of HTTP can help you
with common problems and optimizations. We also give resource-oriented designs
for tough features like transactions, which you may have thought were impossible
to do in RESTful web services.
 
在本章中，我们将我们对于服务设计的早期建议收集到了一块，并加入了新的建议。我们展示了HTTP的标准特性如何帮助你解决一般性问题和最优选择。我们也为比如事务（你可能认为在RESTful风格的web services中不可能完成）这样的强硬特性给出面向资源的设计。
Chapter 9, The Building Blocks of Services
第9章，构建服务块
Here we describe extra technologies that work on top of REST’s big three of HTTP,
URI, and XML. Some of these technologies are file formats for conveying state, like
XHTML and its microformats. Some are hypermedia formats for showing clients
the levers of state, like WADL. Some are sets of rules for building RESTful web
services, like the Atom Publishing Protocol.
 
我们描述额外的工作于HTTP、URI和XML这三个重要的REST的技术之上技术。这些技术中的一些是用于运输状态的文件格式，像XHTML和它的微格式。一些是为了展示客户端状态的控制杆的超媒体格式，像WADL。一些是一组为了构建RESTful风格的web service的规则，如Atom发布协议。
The last three chapters cover specialized topics, each of which could make for a book
in its own right:
最后三章覆盖了几个专题，每一个都可以出一本书：
Chapter 10, The Resource-Oriented Architecture Versus Big Web Services
第10章，面向资源的架构vs Big Web Services
We compare our architecture, and REST in general, to another leading brand. We
think that RESTful web services are simpler, more scalable, easier to use, better
attuned to the philosophy of the Web, and better able to handle a wide variety of
clients than are services based on SOAP, WSDL, and the WS-* stack.
 
我们从总体上将我们的架构和REST，与其他的主要技术进行了比较。我们认为RESTful风格的web services是更简单的，更据扩展性的，更容易使用，与Web的哲学体系更加相容，与基于SOAP，WSDL和WS-*堆栈的服务相比，可以控制更多的客户端。
Chapter 11, Ajax Applications as REST Clients
第11章，Ajax应用程序作为REST客户端
Here we explain the Ajax architecture for web applications in terms of web services:
an Ajax application is just a web service client that runs inside your web browser.
That makes this chapter an extension of Chapter 2. We show how to write clients
for RESTful web services using XMLHttpRequest and the standard JavaScript library.
 
在这里我们讨论适用于按照web services的方式构建的web应用的Ajax架构：一个Ajax应用只是一个运行在你的web浏览器中的web service客户端。这是对于第2章的一个扩展。我们展示了如何使用XMLHttpRequest和标准的JavaScript库为RESTful风格的web services编写客户端。
Chapter 12, Frameworks for RESTful Services
第12章，RESTful服务的框架
In the final chapter we cover three popular frameworks that make it easy to implement
RESTful web services: Ruby on Rails, Restlet (for Java), and Django (for
Python).
 
在最后的章节我们讨论了三个流行的可以容易的实现RESTful风格的web services的框架：Ruby on Rails，Restlet (for Java), 和Django (for
Python)。
 
We also have three appendixes we hope you find useful:
 
我们还有三个附录，希望对您有用：
Appendix A, Some Resources for REST and Some RESTful Resources
附录A，一些REST和RESTful的资源
The first part lists interesting standards, tutorials, and communities related to
RESTful web services. The second part lists some existing, public RESTful web
services that you can use and learn from.
 
第一部分列出了有趣的与RESTful web services相关的标准，指南和社区。第二部分列出了已有的，公开的RESTful web services，你可以使用他们，并获得你想要学习的东西。
 
Appendix B, The HTTP Response Code Top 42
附录B，HTTP响应代码
Describes every standard HTTP response code (plus one extension), and explains
when you’d use each one in a RESTful web service.
 
描述了每个标准的HTTP响应代码（增加一个扩展），并解释了在一个RESTful web service中你何时使用每一个。
Appendix C, The HTTP Header Top Infinity
附录C，HTTP Header
Does the same thing for HTTP headers. It covers every standard HTTP header,
and a few extension headers that are useful for web services.
 

评论

3 楼 sslaowan 2007-12-09  

不知道为什么被投了两票隐藏帖，是因为这样贴出翻译是侵权吗？
不过我觉得这个前言提出的很多观点很值得讨论，这远比之前出的任何一本SOA的书在服务计算这个领域中都更有价值。基于某篇文章讨论，总比空对空要好的多。
  在刚看书名时，觉得RESTful和Web service本身就应该是矛盾的，看了前言后，被作者说服了，过去我所认为的web service都是RPC风格的，有些片面了。
  而另一方面，像Mash-up一类的技术，客户端整合方案，在毛新生看来都是SOA的范畴（见第11期《程序员》）。


服务计算是新成立的一门科学，是计算机科学，信息管理与信息系统，软件工程的交叉学科。目前我做的项目越来越倾向于SOA。而我感兴趣另一项研究是基于语义和基于语用的SOA，有几个同学正在做这方面研究。

2 楼 sslaowan 2007-12-09  

    我一直在思考目前我们项目运用的分布式技术，用于需要支持Web浏览器和RCP客户端，因此我们选择使用了Spring Http Invoker这个在网络上被评为“两全其美”的方案。在写了很多代码后，发现了在REST和RPC中选择是很困难：
    1、过去的远程对象之类的技术都无法跑在HTTP协议上，后来有了SOAP，有了WS*-阵营的Web Service，解决了这个问题。可是现在 Spring Http Invoker一类的技术也可以这样跑了。这一点与REST是一样的。
    2、使用XML作为传输格式是有利有弊的：好处在于平台无关，可读性也不错；缺点在于效率低（拼装和解析都慢），复杂的语义表示的不好。
    而使用Java序列化，直接使用可序列化的Java对象，对于Java程序员而言比较熟悉，效率比XML高得多（je上有篇文章对比过这个）。但是限于Java平台，虽然有技术可以在其它平台上反序列化Java对象，但是毕竟不是主流（还有公司的技术可以将Delphi编译成Java字节码）。
    但如果服务的提供者和消费者都是Java平台，则使用Java序列化的方式则更好。
   3、这似乎是没有争议的。不过从REST的角度去思考呢？想想你写的那些所谓的远程方法都是干什么的呢？是不是可以包括在HTTP的CRUD之中呢？这本书给出了无可争议的证据。但是这只是个开始。但是值得思考的是，数据库模型，给出了REST的强大实践基础。
    当我们不断地去为了新功能去编写远程调用方法时，我在思考，这是否过于复杂。说白了，方法调用无非就是如下公式：
     返回值  方法名（参数）；
   那么既然HTTP协议给了我们统一的方法名，和参数表示法（使用POST写在文本域或隐藏域中，写在URL中，写在HEAD中），XML为我们提供了统一的返回值类型，那么我们真的还有必要去编写自定义的方法吗？
   4、这样一来，我们就倾向于全面拥抱REST，但是完全采用ROA，那对于方法的语义管理将怎样呢？在软件工程中，我们都倾向于使用含有明确语义的变量，即使某个变量是可以重复使用的，但是我们依然倾向于使用不同的变量，以便于维护。
   5、还记得在Ajax in action那本书中，作者演示了如何使用Javascript构造SOAP信封，调用SOAP Web Service，而在这本书中，作者则使用了RESTful web services。
   6、事务。不知道RESTful web services如何处理两个service的事务。或者不会在这样的场合下使用这种风格的services。
   7、关于注册机构。SOA模型中有一个服务注册机构，在我看来这只是一个选项，不一定要有它。我在考虑我们在自己的项目中没有采用WS*-堆栈，是否要使用Observer模式创建一个注册机构，而它真的是有必要的吗？由于我们使用RMI的方式，那么需要生成本地桩代码，这就与可以直接使用WSDL生成本地语言接口不同了，而在我们使用场景下，是不存在WSDL这种东西的。而对于REST风格的服务，发布服务将会更加简单，因为你只是要知道你要处理的数据的格式。而REST下的WSDL对照物又出现了，我还没有研究过。
   8、Axis2开始支持消息模型，那么是否WS*-阵营也开始觉得RPC太麻烦，还是因为希望WS*-可以包含一切？
   9、当SOA遇到workflow，我们在思考REST还是RPC时，又增加了新的选项。当把要做的工作统一为一个调用接口时，对于远程客户端（指人操作的那个客户端）而言，其接口也是简单的。但是不能只是如此考虑，因为SOA下，Server（服务消费者）调用Server（服务提供者）的服务是普遍的。如果这样，又回到了第4点。
   10、关于客户端状态问题。ROd Johnson也强调过使得系统具有延展性需要考虑不在服务端保持用户状态，不管是在Web层还是在业务层，那么，状态应该如何保持呢？
    方案是保存在Cookie中，并强制用户打开Cookie，否则不能进入网站；在其它客户端下，可以在全局变量中保持客户状态，或者到Cookie中去读取状态。
    那么，当同时有两种或多种客户端时，状态还要保存在客户端吗？那意味着要出现重复的对于状态更改的代码。当复用和性能发生冲突时，保证性能是第一位的。

1 楼 sslaowan 2007-12-09  

昨晚在火车上重看Rod Johnson的《J2EE设计开发编程指南》，里面涉及到的远程对象（直接使用RMI或者EJB），XML部分，和MOM，JMS方式的消息传递。联想起这本书中所讲的内容，觉得自己对于服务有了个新的认识。

   所谓Srinath Perera和Ajith Ranabahu说的“RPC风格和消息风格”的分布式架构形式大抵说的就是这样，无论是远程对象还是这里所说的Big Web Serices（过去Axis 1实现）还是更加轻量级的Hessian一类的，都属于RPC，而REST，和MOM则属于消息级的，这可能不是很准确，因为MOM和REST都是特定的大词。记得我刚接触REST时在je上回复别人的讨论，认为在Delphi之类的客户端使用HTTP Connection一类的库和XML解析器来消费从服务端传过来的信息，那时我还不确定这个是不是REST方式，而看了这本书后，我得到了准确的答案。

   其实我们可以看出在这里强调了Web就是服务，每个Web站点都是服务，过去构造Web的方式是给人浏览的，而现在要加入一些技术使得方便人和机器都可以浏览，并给出一致的方式。

   这样就可以回答SOA和ROA的关系，以及或者可以提什么MOA（面向消息的架构），ROA是SOA的子集，RCP方式和消息方式，REST方式的不同在于：远程调用的方法是谁来设计的。使用RPC方式，网络API（见《Ajax和REST Rec~（忘了怎么拼了）》）都是我们自己定义的；而使用消息，调用和发布API是消息中间件或者消息API是别人定义好的，REST方式是直接使用HTTP的固有方法（因此本书作者认为创造RCP的远程调用方法就是在重复造轮子）。从OO的角度来讲，我们要知道数据和方法，数据包括数据内容和结构，那么这样看来，PC风格的Web service使得我们同时要设计方法和数据，而REST风格则只需要设计数据。

    RESTful是将远程机器看成一个巨大的数据库（通过网格使得物理机器虚拟为一个整体），然后Web就是一个RDBMS的类似物，可以进行CRUP操作，这样我们的目标就集中到了对于数据语义的定义，因此就出现了ROA，因为在REST风格中焦点在于设计资源。