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.