|
锁定老帖子 主题：求求你们，千万别再说自己是REST了
该帖已经被评为精华帖
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2008-12-21
http://resources.esri.com/help/9.3/arcgisserver/apis/rest/index.html
dlee有时间看看这个。 |
| 返回顶楼 | |
|
发表时间：2008-12-21
最后修改：2008-12-21
http://www.intertwingly.net/blog/2008/10/21/Progressive-Disclosure
《RESTful Web Services》的作者Sam Ruby对于Fielding的这篇blog的评论。 据Sam说，他还在与《RESTful Web Services》的另一位作者Leonard合作写一本书，专门来解释Fielding的那本关于REST的博士论文。 http://7thgen.info/blog/2008/10/restful-rest/ Neo 写道 … And why expression is the most important thing of all human beings.
最近一些重要的API继续着把REST和HTTP-based等同起来的错误倾向，终于激怒了Web标准专家、REST概念的提出者Roy Fielding博士，并将他的不满用一篇blog表达出来，就是最近非常热的这篇 “REST APIs must be hypertext-driven“，从其中的comments以及programming.reddit上的反馈来看，大部分人还是不明白，Fielding博士在随后的一篇blog中解释了前一篇文章——以及他那篇著名的建立了REST概念的博士论文——为什么这么晦涩，因为在他看来这些本来就是写给特定的专家看的。 对我来说最有趣的部分不是Fielding博士不满的那些对REST的误解和误用——这些其实并不难懂——而是关于语言的表达，很多时候你需要一些伙伴来使用“不一样的方式”说出你想说的话，其效果是完全不同的——当然Fielding博士说他只是没有时间 XD 最后，要是实在看不明白博士的原文，Dare Obasanjo的这篇blog是最好的注解，在所有“勇敢的站出来”尝试为Fielding博士作注的人中，他是最成功的一个——至少我觉得是。 据我所知，Neo是中文世界第一个对Fielding的这篇blog发表观点的人。 Fielding发表这篇blog，这件事情其实并不出我的意外。我在两年前就很奇怪世界上为何一下子冒出来这么多REST专家。那一年，我翻译了《Ajax Patterns and Best Practices》。这本书的内容非常深入，作者Christian Gross宣称他所设计的所有模式遵循的都是REST架构风格。但是Gross先生却没有将REST的来龙去脉讲清楚，甚至只字未提Fielding的那本著名的博士论文。 我后来又阅读了网上流传的很多篇关于REST的文章，仍然无法确信自己真正理解了REST。REST似乎是一个技术界的罗生门，每个人的描述都不一样，而他们都坚信自己的理解才是正确的。 几乎所有网上流传的关于REST的文章都告诉我，REST其实很简单，学习和使用REST都是一件非常愉快的体验。 然而，这与我的体验相距甚远。也许我确实很笨，这些家伙显然都要比我更聪明，生活的比我轻松的多。 我的习惯是如果想要学习某一门学问，就从其源头去学。我学习儒家学说就会自己去读《论语》，绝对不会先去读朱熹的什么《论语集注》。 出于对REST的极大兴趣，我做了一件比一般人更笨的事情：我决定翻译Fielding的那本博士论文。在得到了Fielding的许可后，我和廖志刚等同学花了3个月时间，将那本博士论文全部翻译成了中文。这本博士论文是我翻译过的英文著作中最难的，其中的甘苦只有亲身体验才会知道。 后来我又仔细阅读了《RESTful Web Services》，在徐涵翻译的中文版出版之前，我可能是国内最早通读完这本书的人。 Ruby on Rails对于REST开发有很好的支持，我们基于Rails，并且以REST方式做了很多开发。 我还通读了HTTP 1.1协议（RFC 2616）。 即便如此，在做了这些事情之后，我仍然不确信自己完全理解了REST。你说REST真的是很简单吗？ 现在真相大白了，Fielding对于REST架构风格定下了如此严格的判断标准，世界一下子清静了。 |
| 返回顶楼 | |
|
发表时间：2008-12-21
这篇blog所定义的REST就简直就是REST2.0版本,是不是roy不满于别人炒作他的REST概念一时冲动的结果呢
|
| 返回顶楼 | |
|
发表时间：2008-12-22
最后修改：2008-12-22
引用 dlee说： Fielding的主要意思是说，客户端不应该事先了解服务器端URI的结构和针对每个URI的操作，而是应该通过某种发现机制来确定。 dlee说： 例如我使用浏览器访问一个网站，我先访问其首页，然后首页返回给我带有URI和link和form，指导我去访问其他页面。 dlee说： 这些link和form的URI、针对URI所执行的操作都是有可能变化的。 dlee说： 我如果不通过这种机制，事先在客户端代码中写死了，未来这些东西变了，客户端代码就会完全失效。 dlee说： 客户端不应该对服务器端的URI和针对URI所执行的操作做过多假设，那样客户端和服务器端的耦合就太紧了。 dlee说： 客户端应该通过服务器端返回给它带有超链接的表现来进行状态的迁移。 dlee说： hypertext不一定是html，也可以是带有超链接的其他格式。 Trustno1说： en，那么其他人在争论什么呢？ dlee说： 他们争论这个理想国在实际的Web应用开发中是否有价值。 dlee说： 对于普通Web开发者来说，这样间接的方式是违反直观的。 Trustno1说： 违反直观？怎么说？ dlee说： 比如你设计了一个Web服务的API，在文档里面告诉我可以使用/books/123/comments/55这种方式找到一本书的评论。 dlee说： 我在客户端代码中直接访问这个URI， dlee说： GET /books/123/comments/55 dlee说： 但是Fielding告诉你，你这样做是错误的，你不应该暴露出/books/123/comments/55。 dlee说： 你应该返回给客户端一个hypertext，里面含有这个URI。 dlee说： 然后客户端在服务器返回的这个hypertext的指导下访问这个URI。 dlee说： 但是客户端不应该事先假设服务器端一定会有这样一个URI。 非常非常有意思的说法，但是却让人很疑惑，难道说作为客户端，却要由服务器端来决定其操作？ OK，假设成立，客户端等待服务器返回hypertext，然后客户端再根据返回的结果进行操作（混乱），等等，你服务器又怎么知道客户端要什么呢？客户端又如何告诉服务器其意图？ Fielding博士训导出现在脑海中：“URI，都是通过URI”，O，明白了，那么这个URI从哪来？“hypertext指引”，那么这个"hypertext"指引又从哪来？“URI。。。。。。”，天，先有鸡还是先有蛋啊。。。。。。 对于客户端来说，无论如何，总是要通过一个URI描述其意图，这是无法改变的，为什么还要等服务器再返回一个指引，然后客户端再去根据指引请求？这样的话以后服务器有所变动，而客户端不需更改？真的如此？ 既然总需要有一个URI，当我服务器通过URI了解客户端的意图时，再告诉客户端，你根据某某URI再做一个请求吧，就能达到你的目的了，good，我客户端就再请求一次。。。。。。 能给我解惑一下么？why？ |
| 返回顶楼 | |
|
发表时间：2008-12-30
到底 REST 有什么好的啊？
|
| 返回顶楼 | |
|
发表时间：2008-12-30
其实就是在更高层次定义规则，定义元规则，就要好像一种语言规则
然后我们用这种语言来交流，机器就知道该怎么做，而这个语言规则是稳定的几乎不变的。 就好像汉语规则是稳定的，说出来的话是多样的，大脑作为浏览器他知道怎么理解 |
| 返回顶楼 | |
|
发表时间：2008-12-30
我们所说的每句话都是语言规则的一个具象实例，也就是一个RE，我们必须用RE来交流
|
| 返回顶楼 | |
|
发表时间：2008-12-31
REST的野心很大……
|
| 返回顶楼 | |
|
发表时间：2008-12-31
calmness 写道 引用 dlee说： Fielding的主要意思是说，客户端不应该事先了解服务器端URI的结构和针对每个URI的操作，而是应该通过某种发现机制来确定。 dlee说： 例如我使用浏览器访问一个网站，我先访问其首页，然后首页返回给我带有URI和link和form，指导我去访问其他页面。 dlee说： 这些link和form的URI、针对URI所执行的操作都是有可能变化的。 dlee说： 我如果不通过这种机制，事先在客户端代码中写死了，未来这些东西变了，客户端代码就会完全失效。 dlee说： 客户端不应该对服务器端的URI和针对URI所执行的操作做过多假设，那样客户端和服务器端的耦合就太紧了。 dlee说： 客户端应该通过服务器端返回给它带有超链接的表现来进行状态的迁移。 dlee说： hypertext不一定是html，也可以是带有超链接的其他格式。 Trustno1说： en，那么其他人在争论什么呢？ dlee说： 他们争论这个理想国在实际的Web应用开发中是否有价值。 dlee说： 对于普通Web开发者来说，这样间接的方式是违反直观的。 Trustno1说： 违反直观？怎么说？ dlee说： 比如你设计了一个Web服务的API，在文档里面告诉我可以使用/books/123/comments/55这种方式找到一本书的评论。 dlee说： 我在客户端代码中直接访问这个URI， dlee说： GET /books/123/comments/55 dlee说： 但是Fielding告诉你，你这样做是错误的，你不应该暴露出/books/123/comments/55。 dlee说： 你应该返回给客户端一个hypertext，里面含有这个URI。 dlee说： 然后客户端在服务器返回的这个hypertext的指导下访问这个URI。 dlee说： 但是客户端不应该事先假设服务器端一定会有这样一个URI。 非常非常有意思的说法，但是却让人很疑惑，难道说作为客户端，却要由服务器端来决定其操作？ OK，假设成立，客户端等待服务器返回hypertext，然后客户端再根据返回的结果进行操作（混乱），等等，你服务器又怎么知道客户端要什么呢？客户端又如何告诉服务器其意图？ Fielding博士训导出现在脑海中：“URI，都是通过URI”，O，明白了，那么这个URI从哪来？“hypertext指引”，那么这个"hypertext"指引又从哪来？“URI。。。。。。”，天，先有鸡还是先有蛋啊。。。。。。 对于客户端来说，无论如何，总是要通过一个URI描述其意图，这是无法改变的，为什么还要等服务器再返回一个指引，然后客户端再去根据指引请求？这样的话以后服务器有所变动，而客户端不需更改？真的如此？ 既然总需要有一个URI，当我服务器通过URI了解客户端的意图时，再告诉客户端，你根据某某URI再做一个请求吧，就能达到你的目的了，good，我客户端就再请求一次。。。。。。 能给我解惑一下么？why？ 简单的说，其实用程序就是模拟你上网站的操作。Fielding博士说了,首先会有个起始的标志，就是一个起始的URI，然后根据这个URI获取hypertext，这个hypertext就像是网站的首页，这个hypertext（如：首页）就决定了你客户端（用户）的操作，你根据这个hypertext中的URI发送一个请求，又会获取一个hypertext（进入了网站的另一个页面），这个hypertext又决定了你客户端（用户）的操作，然后再请求，再获取hypertext。。。。。。 其实整个过程的难点就是怎么用程序去理解这个hypertext，个人感觉这一块Fielding博士就是在讲要用语义。 |
| 返回顶楼 | |
|
发表时间：2008-12-31
# Trackback from Sam Ruby
October 21st, 2008 at 3:49 pm Progressive Disclosure… Roy Fielding: I am amused by the people who are valiantly trying to decipher Roy. While I don’t really have much to add, here is what I have… Without intending to take anything away from Roy’s (valid) criticism on labeling, REST… Sam Ruby是restful web service的作者。个人感觉这本书讲的rest，比较接近fielding的理论吧 。。。 |
| 返回顶楼 | |
