REST 簡介

前言

寫這篇是因為我在 滿紙荒唐言，一把心酸淚 裡面有講到

我連REST 的好處都不甚了解，就大張旗鼓的吹 REST 的好？

所以我開始努力 survey REST 的東西，終於在 OSDC 主講 The furture of RoR - The new features in RoR 2.0。原本以為自己已經徹底瞭解 REST，但是隨著時間的逼近，我越來越發現「我不知道 REST 真正的好處」。最後，當我在 OSDC 講完之後，大家就七嘴八舌給我一些意見，越討論越發現我真是個笨蛋

在 OSDC 這種場合，我才是學生，場下聽的強者們才是我的老師。

現在的我，有了大家的加持後，反而越來越有自信了點，我終於允許我在 Blog 寫有關於 REST 的文章。

REST is about Resource

在講 REST 之前，我們來看看Resource 。當你了解 Resource，那麼你就了解了 REST。我們來看看 Wikipedia 這張圖，這個三角形是在講解 Resource 最重要的三個東西，Nouns，Verb，Type。

Nouns

在網路上，每個URL帶給我們的意義其實就是代表各式各樣的資源（Resource），有些可能代表你的個人日誌，有些代表我出去玩的圖片，有些代表你最喜歡的歌手的音樂，有些代表你朋友搞笑的影片。Resource 裡面，Nouns 其實是一個 URL，他代表網路上面 Resource 的唯一的位址，同一個 resource 理論上來說，應該只有一個 URL 代表這個 Resource。用超過一個 URL 來代表同一個 Resource 是不夠漂亮的方式。

Type

而 Type 是什麼呢？我們剛剛講 URL 代表Resource 的位址。但是 Resource 其實跟大家想的有點不太一樣，resource 不是只代表一個檔案，他是代表一個概念。舉個例子，這張圖片
是 一張PNG圖片，裡面是我的 Email 。他的位置是在 http://www.thegiive.net-a.googlepages.com/image.png，但是如果我今天將這個 PNG 轉檔成為 JPG，他的位置就變成了 http://www.thegiive.net-a.googlepages.com/image.jpg。雖然兩者的 URL 不相同，但是對我們來說，PNG 跟 JPG 這兩張圖其實代表的意義是相同的，裡面的圖案就是我的 Email。

所以，儘管 Format 不同，他們依舊是同一個 Resource，而這些 Format 就是 Type

好， 這些東西大家應該都可以了解吧。我們問些奇怪的問題，假設今天有一個 XML file http://www.thegiive.net- a.googlepages.com/image.xml 這個XML檔案裡面記載著我的 Email 帳號

<xml>
<email>thegiive at gmail dot com</email>
</xml>

那麼這個 XML File 跟上面的圖，算是同一個 Resource 嗎？是的，雖然 XML 跟 JPG ，PNG 是完全不同的東西，但是他們都記載同樣的意義，那個意義就是我的 Email 帳號，也就是他們代表同一個 resource。

如果你能夠接受不同格式的檔案其實代表同一個 Resource 的想法，那麼今天這個網址

http://abc.com/blog/1

如 果以 HTML Format 來說，他可能是一個可以顯示在 Browser 上面的 HTML ，裡面記載這個 Blog 的內容。但是如果是 XML Format，他可能是一個記載這個 Blog 作者是誰的XML 。如果是以 RSS Format 來看，他可能是這個 Blog 的最新文章。但是儘管 Format 不同，內容不同，但是他們還是代表同一個 resource ，也就是這個 Blog。

在 Web 上面，Resource 是一個概念，而不僅僅是一個檔案。一個 resource 可能有各種不同的 Content Type，但是依舊代表同一個 resource。

Verbs

至於三角形的最後一角Verbs ，就是操作 Resource 的方式。我們該如何操作網路上各式各樣的資源呢？

Web 用宏觀來說，其實就是一個超級大的資料庫，裡面有各式各樣不同的 resource，每個 URL 都是指向各種不同的 Resource，我們每天上網，其實都是藉由 HTTP 來 request 各式各樣不同的 Resource。

既然 Web 根本就是一個網路上面 Resource 的資料庫，每個 Resource 都是跟資料庫裡面的 Data Entry 類似。那麼有用過資料庫的人都知道，我們每天對資料庫的每個 Data Entry 做四個動作，也就是經典的 CRUD（Create，Read，Update，Delete）。盡管 SQL 指令再多，其實我們對資料庫的操作，都超不出 CRUD 這四個動作。

那們，我們對 Web 上面的 resource，有沒有相對應的 CRUD 呢？

RFC 2616 裡面講到， HTTP 1.1 一共有八個 method（我在演講中提到只有四個 Method，是錯誤的，謝謝聽眾指正。），裡面有兩個 Method 是大家不可能不懂的

• GET
• POST

雖然 HTTP 定義八個 Method之多，但是大家在 Coding Web 時只使用這兩個 Method。
原因很簡單，因為最多人使用的 HTTP Client，也就是 Browser，只支援 GET 和 POST。所以，我們之前的 Coding，都是只用 GET 和 POST 來對 Web Resource 來做 CRUD。

CREATE：POST http://abc.com/users/create/
READ：GET http://abc.com/user/show/1
UPDATE：POST http://abc.com/user/update/1
DELETE：GET http://abc.com/user/delete/1

我們必須用部份的 URL 來表示我們對這個 Resource 的操作，這樣做也沒什麼不好，但是要知道 URL 其實是要來指定 Resource 位置的，URL 不是拿來表示 Verbs 的。而且這樣做等於我們使用四個 URL 來表示同一個 Resource，這跟一個 Resource 理論上來說只能有一個 URL 牴觸。

RFC 定義的 HTTP 1.1 裡面，其實有四個 Method 是直接 Mapping 到 CRUD 的，那就是 GET，POST，PUT，DELETE。既然已經 HTTP 1.1 已經有對應好的 Method，那為什麼我們要捨近求遠，硬是要使用 GET POST 來設計出 CRUD，為什麼不用原本就規定好的 Mapping 來做 CRUD 呢？

沒錯，這就是 REST。讓大家不需要再捨近求遠，不需要用非 Web Standard 的方式來做 Web Development。

REST 的詳細定義就請看 Wikipedia上面的介紹， 本人就不詳細敘述了。在定義上來說，REST 並不等於 HTTP，REST 是一種 Architectural Style，而非一種 Standard，所以 REST 並沒有 toolkit ，也沒有 W3C Spec。相對起來，HTTP 才是一種 Standard ，有相對應的 toolkit，W3C Spec。HTTP 是一種 REST 的實做，也是最成功的實做。但是我們以實用為主，並不是那麼在乎太過細部的差別，所以以後我不會太強調 REST 跟 HTTP 兩者意義上的區分。

華文 REST 討論文章網摘

說到這就要講到我在 滿紙荒唐言，一把心酸淚，裡面所講到的

Rails 1.2 + REST : 討論 Rails 的核心價值 這篇更是可笑，我連REST 的好處都不甚了解，就大張旗鼓的吹 REST 的好？

我當然不是作學問態度那麼隨便的人，所以我開始花時間去整理大家對 Rails 1.2 裡面 REST 的用法以及玩法，先看看大家怎麼講，再慢慢自己學習 REST 的概念也是很好的。

以下就是華文 REST 討論文章網摘大集合。

• REST：Rails 1.2的意义，以及一个翻译接力的发起 - 孟岩 - CSDNBlog
  引述 :『Rails 1.2的主要亮点是REST。可以这样说，经过这次升级，Rails成为第一个把REST作为核心思想的主流Web框架，从而把其他的竞争性的敏捷Web开发框架又一次抛在了身后。』
  孟岩說明 Rails 1.2 對於 REST 的東西
• Architectural Styles and the Design of Network-based Software Architectures
  著名的Web技术专家、HTTP等诸多Web协议的主要起草人Roy Fielding从加州大学Irvine分校获得博士学位，其博士学位论文中描述了一种分布式软件的体系结构风格，被称为REST。
• 在Rails中探索资源的世界——7月9日David Heinemeier Hansson演讲的翻译稿（部分） - 孟岩 - CSDNBlog
  引 述 :『今年7月份举行的RailsConf 2006上，David Heinemeier Hasson作了一个主题演讲，很清楚地讲了Rails 1.2中对于REST的设计，以及REST风格给Web应用设计思想所带来的革新。我第一次看到这个视频，就认为这可能是对Web服务端开发具有历史意义 的一次演讲。』
  孟岩對於 DHH 的翻譯
• Rails 1.2 + REST : 讨论 Rails 的核心价值-rails-Ruby
  引述 :『REST的意义不在于做一个网站，而在于网站间的互相调用变得异常直接。网站间的调用，也可以理解成不同系统间的调用。
  
  比如一个公司的CRM、workflow、财务系统、website...可以是一套大系统，那样太繁杂，也可以是分别几个独立的系统（decoupled systems），但是互相调用metadata就会非常不方便。一般有这么几种方式实现（从差到好排序）：
  1、A系统直接调B系统的数据库
  2、用程序访问B系统的网页，取出A系统需要的东西
  3、各系统把经常要访问的功能写成web service
  4、各系统做一套api
  5、REST
  
  上面的例子说的是公司系统，大众网站也是如此，如果大家都用REST，mashup也会更容易，好的应用会更多。』
• 也谈一下我对Rails 1.2中 Restful的理解--Ruby
  引 述 :『Constraints is FreedomCRUD 形成了一种约束，把我们从权衡Controller和action风格这种无聊的事情中解脱出来,按照统一的风格来编写程序以及构造URL。使我们有精力 关注更重要的事。REST还避免我们编写大的Controller。可曾有人后悔曾经写过的包含十几个action的，并且action之间毫无联系的 Controller呢？其实大部分情况下，一个Controller有7个action就够了，并且这些action关注于同一Model，大大提高了 正交性.』
• 与Rails REST亲密接触--Ruby
  引 述 :『Rails REST特性可以让Web服务技术用平台独立或编程语言独立的方式相互通信,各个不同应用程序之间的远程过程调用从来都是相当麻烦，今天试用了一下 REST，相比SOAP 和 WSDL 的确非常简洁好用。现在能够领会DHH在Rails的演讲中说的：“我不认为Rails应该向外部世界屈服，恰恰相反，Rails正在有力地让外部世界向 我们屈服。”这是狂，不过DHH也有资格狂！』
• 我对Rails 1.2中 Restful的理解-qiezi -JavaEye技术社区
  引 述 :『我总觉得REST应该用于提供数据而不是页面，还是用用户和圈子作例子吧，感觉顺畅一些。比如某个用户的页面，他选一个圈子，点击“加入”就加入了这 个圈子；而圈子的管理员也可以选择用户，并点击“添加”把用户加入圈子。这里2个页面完成的是同一个操作，都是创建一个用户－圈子的关系，但操作完以后的 页面转向会不同。如果用REST来提供页面，如何来处理这些转向？另加参数？那不是搞复杂了嘛。所以我觉得应该是浏览器上通过AJAX请求这个 action，返回数据，浏览器脚本把数据处理成显示，这也是AJAX最适合的方式。如果只提供数据，实际上不需要7种action，4种就可以了』
• 我对Rails 1.2中 Restful的理解（二）-qiezi -JavaEye技术社区
  引述 :『ESTful核心就是资源，把关系也看作是资源，所以用户加入和退出组可以改成用户与组的关系这个资源的创建和删除。基于这一点我觉得RESTful应该翻译为REST风格，不给它个合适的中文词汇来代替，总是理解起来有些偏差。』
• REST的意义在于：-rails-Ruby
  引述 :『设想REST流行起来，新网站都缺省地提供符合REST标准的API，整个internet就是一个巨大的类库，这才是真正的webOS。这才是REST的魅力所在，是激动人心的地方，不是仅仅为了某单个项目的优化。』
• Rails 1.2 REST + Adobe Spry-rails-Ruby
  引述 :『ails生成XML轻而易举，Rails 1.2的REST也是一项另人心动的功能，而Spry也是以资源作为操作对象，这2者结合会发生什么？我试着学习Spry的内涵，并结合Rails做点测试性应用，以确定是否值得迁移稍大点的项目到它上面。』
• 
  
• G小R裝用功: Rails RESTful 初探
  引 述 :『在許多地方看到了Rails 1.2將支援REST的消息，但是好像沒有在中文網頁說明rails是怎樣去實作REST的，那麼就來自己try try看囉...目前看到最重大的改變有兩項：1. scaffold_resource generator2. route map.resource』

iHower REST 系列

• RESTful Design 雜談 at {|ihower.idv.tw| blog }
• 引 述 :『重點是了解 resources 觀念: 為每個 resource 用單一 URI 定位，忘記用不同URL syntax來觸發不同動作的傳統思維吧(別用 ?action=somepage 之類的東西)，URL應該是名詞而不是動詞。設計這個 resource 使用哪種 (HTTP) verb，設計有哪些 content types。』
• Rails RESTful 實作 at {|ihower.idv.tw| blog }
  引述 :『本來這篇想寫的仔細點，不過後來我發現AWDwR第二版講 Resource-Based Routing 的頁數還不少(十幾頁吧，還蠻詳細的)，要用 Rails 的人應該都去買一本，我想我這裡就不巨細靡遺了… :p』
• 什麼是REST跟RESTful? at {|ihower.idv.tw| blog }
  引述 :『什麼是REST?
  
  REST 是一種分散式超媒體系統(如WWW)的軟體架構風格，你可以想像它是一個良好設計的Web應用程式規則: 一組網路Web頁面(虛擬的狀態機器)，其中 Client 透過點選超連結(狀態變換)，結果是下個Web頁面(表示應用程式的下一個狀態)。』
• Rails RESTful 相關工具 at {|ihower.idv.tw| blog }
  引述 :『Rails RESTful 系 列 彈 第四篇，我在這裡做些 Rails RESTful 工具介紹，相關文章有 REST tools for Rails 1.2。』
• Rails RESTful ActiveResource 先睹為快 at {|ihower.idv.tw| blog }
  引 述 :『我們花了好幾篇學習為何 RESTful 跟如何用 map.resources 來架出 server-side provider，而具體的重大好處則會在 ARes 中體現出來，我們可以像對 ActiveRecord 的物件操作一樣來處理 ARes，只是它的內部運作對象變成 Resource 而不是 Database (你感覺不到你在用Web APIs :p)。』
• Rails RESTful 制約即解放 at {|ihower.idv.tw| blog }
  引述 :『DHH的投影片提到一個概念:
  
  Constraints are liberating (a straight jacket for your mind)
  
  這裡指的 Constraints (制約) 是什麼? 我想指的是 Controller 不出以下七種 action』

我的更多書籤 @ HEMiDEMi - 共享書籤

Models 需要分目錄放置嗎？

我以前一直在想的問題 『我現在的 Project 程式碼 Model File 會不會太多？需不需要分目錄來放置？』很快的就發現到，大家想的問題實在很相近。 Caiwangqin’s blog有一篇 将Rails的Models分目录存放 的文章，裡面提到如何將 Model 分目錄放置的方式 ，但是也提到他認為不需要分目錄放置

Rails使用固定的规范省掉了复杂的config, 一个Web app如果只有20张以下的Table，是不需要分目录存放Models的，如果超过这个数量，我认为也是应该将一个大的Web app分割成多个小的App来做，更有利于以后的分布和维护。

如果仔細想想，我還蠻同意這樣的看法。

雖然手邊最大 Project Models 程式碼高達 45 個，但是目前還沒有任何困擾，因為 Convention over Configuration 強制 Model 跟 Table 同名的因素，會讓你完全不會找不到你要的 model file 。

另外一個因素是，我受到這篇的啟發

REST的意义不在于做一个网站，而在于网站间的互相调用变得异常直接。网站间的调用，也可以理解成不同系统间的调用。

現在已經跟 Partner 討論如何將部分功能以 REST 方式拆出去這個系統。原因當然是為了不讓系統太過龐大，改了這部分的 code ，又得擔心會不會影響整體的穩定。目前已經想到要將整個系統拆成一個主系統，三到四個小系統，如果順利拆出來的話，最大系統的 Model file 數量應該也不會高於 30 個。

也就是說，純粹以我這個 Project 來考量的話，目前沒有將 Model 分目錄的必要性。


PS. 這篇文章講到如何Models File 分目錄放置 ，並且也有範例。

时间: 2006-12-08 14:10 评级: (0位会员评分) 引用 推荐 收藏

在control里面加上include Location就可以了

延伸閱讀

• 将Rails的Models分目录存放
• 我想将模型对象放在models的子目录下，应该怎么做？

Rails 1.2 + REST : 討論 Rails 的核心價值

我還記得以前我跟另外一個人討論 ORM 的時候，還有人說到 『ORM毫無意義可言，他一點實用價值都沒有』。的確在那時的世界裡面，ORM是被視為拖累框架速度的兇手， ORM無法像 SQL 語法一樣完全處理各種不同的情況，ORM沒有任何實用的必要，他只是一個科學家的玩具而已。但是 Ruby on Rails 一推出，在如此漂亮方便好用的 ORM 之下，彷彿任何網頁開發架構沒有 ORM 好像就遜了一截。於是每個新出的 Framework 開始學習 Ruby on Rails，加入 Active Record 類似的機制，彷彿 ORM 是所有 Framework 必須也是必要的機制。

到底在 Ruby on Rails 之前，這個世界是沒有 ORM 的需求，還是只是我們這些凡夫俗子看不到這樣的需求？

當我提到 Rails 1.2 導入 REST 的時候，大家的問題又變成『為什麼要用 REST？』『REST 有其他的好處嗎？』，其實說實在話，我不知道 REST 到底會帶來什麼樣的革命。或許他也只是個行銷名詞。孟岩先生曾經對這個事情發表評論

Ajax的出现标志着RIA时代逐渐走来，客户端将不再是清一色的HTML页面，也可以是一个Ajax的程序，通过 XMLHttp向服务器发起PUT和DELETE请求。这样，就要求服务器端在四动词的背景下重新思考应用的构造。传统上，服务器端应用只是通过REST 风格将部分服务暴露出来。而Rails 1.2则直接将REST直接作为构建整个Web应用的中心，这才是Rails 1.2的独特之处，也是张显Rails社群离经叛道和卓尔不群的地方。为了要采纳REST风格，Rails 1.2革新了Web应用的构造思想，整个领域建模的思想都有所变化。现在整个Rails社群都应当准备向REST时代迁移。

說實在話，我還是無法很準確的抓住孟先生的點。因為如果眾多網頁程式設計師對於 REST 的好處跟壞處都不甚明瞭，那要怎麼推行 REST 呢？當大家都不用 REST ，那麼使用 REST 有任何意義嗎？但是看到 DHH 在 2006 Rails Conf 講解了 Rails 1.2 對於 REST 的導入的這篇演講

之所以今天我们会在这里聚会，之所以Rails是今天的Rails，恰恰因为我们对很多事情说了“不”，恰恰是因为我们将很多人 拒之门外。如今Rails被越来越多的人接受，但我并不认为因此我们就可以背离先前的原则。所以，尽管我毫无疑问地支持Thomas的很多实用的建议，但 对他的论调则不以为然。我不认为Rails应该向外部世界屈服，恰恰相反，Rails正在有力地让外部世界向我们屈服。

凡事迎合大眾到底是金科玉律，還是庸人的想法。我回想到當我接觸 Ruby on Rails 之前，我似乎也是座落在『ORM毫無意義可言，他一點實用價值都沒有』這一群人。現在的我呢？又到了哪裡去呢？回到 REST 這個話題，到現在為止我還是不知道 REST 能夠為我帶來什麼東西？但是我願意去嘗試看看，因為

到底在 Ruby on Rails 1.2之前，這個世界是沒有 REST 的需求，還是只是我們這些凡夫俗子看不到這樣的需求？

漸漸的我發現到， Ruby on Rails 的核心價值不在於他的方便好用，其實就是在於 DHH 那一句『我不認為Rails應該向外部世界屈服，恰恰相反，Rails正在有力地讓外界世界像我們屈服。』。既然 REST 是一個網頁開發正確的方向 , 大家就勇敢的走下去吧 。不要像個隨波逐流的人們 ，勇敢的向前面繼續邁進吧！

有些人迎合世界的需求，有些人用良好的產品去創造這個世界的需求。

在 iPod 剛推出的那年，所有評論一面倒的偏向『這個世界並沒有任何硬碟式的 MP3 Player 的需求』，現在那些人又到哪裡去了呢？而 iPod 最後成功的原因很多，但是最主要的原因在於他放大硬碟式隨身聽的好處（一次可以將所有的歌放進去），而且他的實做讓硬碟式隨身聽的缺點縮小，所以他成功了。(註1)

同樣的道理 , 真正讓 REST 可以起來的原因，是 Ruby on Rails 到底能不能實做出一個很方便，很好用的 REST 架構？而非去問現在市面上到底有沒有 REST 的需求。當 Rails Team 真的做出一個很棒的 REST 架構的 Framework ，可以放大 REST 架構簡潔的優勢，卻又可以縮小 REST 的缺點，那全世界都會因為 Rails 而轉動，就跟當初的 Active Record 一樣。但是如果有這個需求，但是實做無法吸引大家使用，也不會有人去使用的。加油吧，Rails Team。

延伸閱讀

• 在Rails中探索资源的世界——7月9日David Heinemeier Hansson演讲的翻译稿（部分） - 孟岩 - CSDNBlog
• 在Rails中探索资源的世界——7月9日David Heinemeier Hansson演讲的翻译稿（部分）
• Architectural Styles and the Design of Network-based Software Architectures

註1 ：

iPod 當初讓評論家否定的原因是因為

1. 硬碟式隨身聽用電量多，電池恐怕撐不住
2. 硬碟晃動時容易有挑針的現象
3. 硬碟歌太多了，你很難用隨身聽這樣的小螢幕選擇幾千首歌。

而 iPod 最後出來的成品 , 我們可以發現到 Apple 用了不少心思讓這些缺點都極小化 , 最有名的例子在於圓形轉盤的設計 , 讓人們可以快速的從第一首選到第一千首 。