大规模视频网站的计费与流量管理
本次分享将会就大规模视频网站的计费与流量管理这个话题，从操作层面细细进行讲解和分析，为系统工程师们揭示平日里我们没有关心的另一些内容。同时也希望本次分享能揭示行业中的一些“潜规则”，让互联网行业的流量与带宽管理更为开放与简洁。
本次演讲视频录制于QCon杭州2011。
新闻
该内容已经被标记书签！
标记书签错误，请重试！
文章：深入浅出REST
作者 Udi Dahan 译者 苑永凯 发布于 2007年12月25日
尽管Web无处不在，可许多人还是很难将Web的架构原则应用在自己的系统之中。表述性状态转移（REST），Web背后的架构，正在迅速地成为架构师在开发分布式系统时考虑到的可行方案之一。在这篇发表的InfoQ中文站文章中，Stefan Tilkov深入研究了使用REST设计系统的方法，并考察了传统基于接口（interface-based）的设计方法与其的异同。
不知你是否意识到，围绕着什么才是实现异构的应用到应用通信的“正确”方式，一场争论正进行的如火如荼：虽然当前主流的方式明显的集中在基于SOAP、WSDL和WS-*规范的Web Services领域，但也有少数人用细小而洪亮的声音主张更好的方式是：REST。
Tilkov在一开始就列举了REST的关键原则，使得对这个充满争议的架构的学习变得简单了许多：
- 为所有“事物”定义ID
- 将所有事物链接在一起
- 使用标准方法
- 资源多重表述
- 无状态通信
这些关键原则带来的一些好处列举如下：
对事物使用一致的命名规则（naming scheme），这样你就不需要提出自己的规则——依靠某个已被定义，在全球范围中几乎完美运行，并且能被绝大多数人所理解的规则。
还有：
统一接口使得所有理解HTTP应用协议的组件能与你的应用交互。通用客户程序（generic client）就是从中受益的组件的例子，例如curl、wget、代理、缓存、HTTP服务器、网关还有Google、Yahoo!、MSN等等。
对于那些对REST背后理论感兴趣的人，Tilkov还给出了基本情况介绍，以及这个领域权威内容的链接。
阅读全文：深入浅出REST
不错!支持!
发表人
shinichi kudo
发表于
Re: 不错!支持!
发表人
zhou Richard
发表于
翻译的真好
发表人
zane dennis
发表于
Re: 翻译的真好
发表人
Yuan Shayne
发表于
Re: 翻译的真好
发表人
Zhang Gavin
发表于
真的很好
发表人
Tan Benjamin
发表于
Re: 真的很好
发表人
wang shi
发表于
还是有疑问，请帮助解答。谢谢
发表人
YF CAO
发表于
Re: 还是有疑问，请帮助解答。谢谢（上一个帖子中有乱码，重新发一下）
发表人
YF CAO
发表于
Re: 还是有疑问，请帮助解答。谢谢（上一个帖子中有乱码，重新发一下）
发表人
shinichi kudo
发表于
Re: 还是有疑问，请帮助解答。谢谢（上一个帖子中有乱码，重新发一下）
发表人
Zhang Gavin
发表于
Re: 还是有疑问，请帮助解答。谢谢（上一个帖子中有乱码，重新发一下）
发表人
liu cangui
发表于
Re: 还是有疑问，请帮助解答。谢谢（上一个帖子中有乱码，重新发一下）
发表人
Spring Hai
发表于
我所不明白的问题
发表人
Xu Alex
发表于
Re: 我所不明白的问题
发表人
wang shi
发表于
Re: 我所不明白的问题
发表人
Spring Hai
发表于
翻译的真好，终于让我对REST理解了，原文作者写的真是深入浅出，学习REST入门必读
发表人
wang shi
发表于
请教：关于无状态
发表人
Shi Stone
发表于
Re: 请教：关于无状态
发表人
Wang Frank
发表于
Re: 请教：关于无状态
发表人
wei zhang
发表于
Re: 请教：关于无状态
发表人
果 林
发表于
Re: 请教：关于无状态
发表人
Song Sam
发表于
Re: 请教：关于无状态
发表人
zeng yi
发表于
有没有完全否和Rest的应用啊，可以参考一下啊，那样更有说服力啊
发表人
xu paul
发表于
Re: 有没有完全否和Rest的应用啊，可以参考一下啊，那样更有说服力啊
发表人
cnoss cheng
发表于
Roy的论文中文版地址
发表人
Song Sam
发表于
文章太抽象
发表人
woo sam
发表于
RE
发表人
刘 欢
发表于
1
发表人
wei yajie
发表于
为何不从REST的优点进行讨论呢？
发表人
许 萍
发表于
POST URL的例子举错了
发表人
G bluethinking
发表于
-
我还以为这篇文章被遗漏了呢，快一个月了吧，终于有人翻译了，质量不错，赞一个!
-
比论文通俗易懂多了
-
谢谢支持
主要还是原文自身比较通俗:) -
确实比REST论文的确通俗易懂多了，准备再去看一遍论文。
-
看了此文，虽然较那Fielding的那篇论文通俗易懂，但还是没能解决我长期以来的疑问。
各类关于REST的文章都指出，需要给每个资源指定一个URI，那么，这个URI是指什么呢？我一直将URI与URL等同起来看待，虽然我知道它们之间在定义上是有区别的，但在我们的实际运用中（至少是一般情况下），URI是可与URL赞同的。在网上搜索了一些资料，没有哪篇文章能通俗地讲清楚URI与URL的区别。例如：www.***.com/orders.aspx?id=5，这是一个URL，但也可以说是一个UR...
另外，每个资源在系统中本来就应该是有唯一的标识符了吧？系统中的一个图片、一个文本文件、一个处理订单的aspx或jsp页面，这些都应该是“资源”吧？它们的URL就是唯一的呀？还需要为其指定一个唯一标识符吗（指URI）？
另外，概念说了那么多，那么究竟一个REST架构的系统应该怎样设计呢？以一个简单的例子为例：
在我们之前的概念中，如果要对订单进行操作，会有一个Class来处理订单的一些方法，如：GetAll()，GetByID(int ID)，Delete（int ID）等等。然后我们会提供一个名为Order.asmx的Web Service来依据参数的不同来调用不同的方法并返回XML格式的结果。
那么，REST又有何不同呢？
请指教。谢谢。 -
看了此文，虽然较那Fielding的那篇论文通俗易懂，但还是没能解决我长期以来的疑问。
各类关于REST的文章都指出，需要给每个资源指定一个URI，那么，这个URI是指什么呢？我一直将URI与URL等同起来看待，虽然我知道它们之间在定义上是有区别的，但在我们的实际运用中（至少是一般情况下），URI是可与URL赞同的。在网上搜索了一些资料，没有哪篇文章能通俗地讲清楚URI与URL的区别。例如：http：//www.***.com/orders.aspx？id=5， 这是一个URL，但也可以说是一个URI吧？我用代码依据这个URL初始化一个URI后，得到的“绝对URI”是与这个字符串相同的。
另外，每个资源在系统中本来就应该是有唯一的标识符了吧？系统中的一个图片、一个文本文件、一个处理订单的aspx或jsp页面，这些都应该是“资源”吧？它们的URL就是唯一的呀？还需要为其指定一个唯一标识符吗（指URI）？
另外，概念说了那么多，那么究竟一个REST架构的系统应该怎样设计呢？以一个简单的例子为例：
在我们之前的概念中，如果要对订单进行操作，会有一个Class来处理订单的一些方法，如：GetAll()，GetByID(int ID)，Delete（int ID）等等。然后我们会提供一个名为Order.asmx的Web Service来依据参数的不同来调用不同的方法并返回XML格式的结果。
那么，REST又有何不同呢？
请指教。谢谢。 -
为什么要把REST跟SOAP对立起来？
JSP,ASP,PHP难道不也是对HTTP的“滥用”吗？（按照REST的原则）
电话线原本是给电话用的，但是后来人们用它来发传真，又用调制解调器上网，再后来ADSL，现在ADSL+.在这种途径上人们不断地挖掘潜力.为什么HTTP就不行呢？ -
我觉得之所以强调URI有别于URL就是为了指明RUI并不指代地址，而强调的是标识符。
另外.../orders.aspx？id=5 这种应该不是REST风格的URI，REST风格应该写成类似.../orders/5的样子。
还有你提到的图片，网页，文本文件等应该是资源的表现形式，跟资源并不完全等同。
至于GetAll()，GetByID(int ID)等方法我认为是符合是REST风格的，因为并没有出现GetAllOrders()，GetOrderByID()等特定的API，只要这些方法是统一接口中规定的操作就可以。如果出现了统一接口之外的方法那就要考虑是不是对资源的抽象有问题。 -
REST这东西我认为当你真的有需要的时候再来学习比较容易理解，否则强行学习理解，容易越学越糊涂。
-
WS*这些东西过分强调服务端能力了，而没有挖掘Internet基础设施的能力，这样对伸缩性产生了很大的问题，而且像文中提到的链接能力这些都存在问题。Web之所以这么流行，就源于其链接的能力。
根据我个人的理解，现在很多REST的倡导者在说一些技术对HTTP的“滥用”，其实是一种妥协的说法，他们是怕自己的言行激怒一些读者，其实他们真正想说的就似乎现在很多技术在“误用”HTTP。
其实正像你说的，现在就是在挖掘HTTP的潜力。 -
同感！
-
文章不错，最近也一直在了解这方面的东西，感觉SOAP与Restful WebService并不是冲突的，而是不同的实现方式罢了。我觉得在应用中关键是把业务方法和HTTP的方法和URI做很好的映射。
-
RESTful的无状态要求服务器不保存客户端状态，也就是说放弃原先我们常用的Session，那么在有些应用中，比如说银行客户端，比如说简单的论坛，在验证过用户后才开放资源给用户访问，没有Session，服务器难道每次都要重新验证用户么？是通过cookie么？可是很多用户出于安全考虑是关闭浏览器的cookie功能的。
-
很简单，Rest并不是万灵药，在面对不同的应用类型上不可能全都适合，个人认为高安全性可靠性的应用目前的Rest框架是很难达到要求的
-
有没有完全否和Rest的应用啊，可以参考一下啊，那样更有说服力啊
-
向大家推荐一个REST的Java实现,并附加有例子
code.google.com/p/jrest4guice/
特点:
* 基于GUICE，内置带事务的JPA实现
* 零配置式服务声明
* 服务的自动扫描注册
* 非侵入式，用户不需要实现特定的接口来实现Restful服务
* 支持Post. Get. Put. Delete操作
* 灵活的注入(支持上下文环境request/response以及参数的自动注入)
* 与JAAS的无缝集成
* 支持分布式资源对象 -
是不是需要使用http basic,http digest, WSSE来实现?
-
所谓无状态, 指的是通信链接方式的无状态.
我们用对URI的访问来说明的话:
对URI的访问是不能依赖于访问协议的状态, 比如Http的Session机制.
当然, 你的应用肯定是可以有状态的.
为了解决你的应用有状态, 你又不能依赖于在session里面传递状态的话, 你应该将状态也变成URI的一部分. 由于在资源的标识符URI中加入状态,同样会使用设计不能REST full.
于是作者才强调: 不能简单地将一些session状态绑缚在URI上，然后就宣称这个应用是RESTful。 -
谢谢支持
主要还是原文自身比较通俗:)
你好，我想转载一下，可以吗？ 我会注明作者和原文网址 -
统一资源标识符URI是为了强调资源的唯一性，就像你的身份证，肯定是全国唯一
-
状态是不是也一样可以作为资源进行管理呢？比如论坛登录的问题，可以定义一种资源login，uri为example.com/login，某用户登录后，创建一个新的资源标识其权限，uri为http...
-
文章里的中文版论文地址已经失效了，找到一个新的。
-
文章太抽象
-
千万别拿身份证做例子，身份证是不唯一的。有150万身份证号是重的。
-
我个人的理解是每个都有应用场景的局限吧，SOAP与Restful WebService应该并不冲突的。像你所说的例如银行客户端等对来源者有强制验证的场景，还是SOAP好些吧。
-
讲的不错
-
讲的还行
-
REST的优点
可以利用缓存Cache来提高响应速度
通讯本身的无状态性可以让不同的服务器的处理一系列请求中的不同请求，提高服务器的扩展性
浏览器即可作为客户端，简化软件需求
相对于其他叠加在HTTP协议之上的机制，REST的软件依赖性更小
不需要额外的资源发现机制
在软件技术演进中的长期的兼容性更好 -
“在RESTful HTTP方式中，你将通过组成HTTP应用协议的通用接口访问服务程序。你可能会想出像这样的方式：”
这句话下面的图里，POST的 URL例子错了，不应该是Add，而应该是Update，PUT在HTTP中才表示添加。 -
关于如何将你举例的 WebService 转为 REST 风格，我觉得在此文章中关于“使用标准方法”这一原则的阐述中已经有解答了。
-
我觉得此文也并没有把 REST 和 SOAP 对立起来的意思，文中关于“使用标准方法”这一原则的阐述中有一段话：“在第一种方法中，你拥有许多操作，许多种类的数据以及固定数量的“实例”（本质上和你拥有的服务程序数量一致）。在第二种方法中，你拥有固定数量的操作，许多种类的数据和许多调用固定方法的对象。它的意义在于，证明了通过这两种方式，你基本上可以表示任何你喜欢的事情。”，SOAP就属于这里说的第一种方法，REST属于第二种方法。
31 条回复
关注此讨论 回复