2010-07-25 64 views
1

我對這個派對有點遲到,但我想圍繞REST應該如何工作,無論是在一般還是在Ruby on Rails上。我已經在網上閱讀了大量關於這方面的文章,但仍然覺得我沒有得到大局。在Rails概念上理解REST

REST據我所知,是一系列的願望聲明,最終的淨結果是URL應包含處理請求所需的所有信息,並且不應該能夠更改服務器和其他一些具體的指導方針。

據我所知,Rails中的REST基於CRUD,也就是說,每個模型都有一個創建,讀取,更新和刪除操作。這些操作中的每一個都通過一組類似的URL訪問,這些URL通過映射路由中的資源而生成。因此,一個登錄URL正在創建一個用戶會話,因此該URL看起來像example.com/session/new帶有POST,而註銷將帶有POST的example.com/session/destroy。

以這種方式標準化URL的好處究竟是什麼?這讓我覺得以犧牲人的可讀性爲代價來優化機器的可讀性。我知道你可以在路徑文件example.com/login中重新映射到example.com/session/new,但這只是我沒有明顯收穫的一個步驟。

現在開發一個使用傳統路線的網站被認爲是非常糟糕的做法嗎?

此外,這些CRUD操作中的每一個都應該能夠響應該請求所尋求的任何類型的響應。因此,example.com/tasks的相同鏈接也可以在example.com/tasks.xml中調用,以獲得結果的xml表示,或者針對json表示的example.com/tasks.json。

這是說,RESTful API只是網站上的常用鏈接,但附加了xml?我覺得Web API會以這種方式表現出來很奇怪,很尷尬,但這似乎是我讀過的所有內容所暗示的。我更習慣於看到有像example.com/api/tasks這樣的鏈接來獲取任務列表的API。這種方法的優點究竟是什麼?

+0

「犧牲人的可讀性」?我認爲正好相反,堅持一個特定的URL方案,一切都讓它變得簡單易懂和易於使用。 – deceze 2010-07-25 01:52:33

+0

但是,已經有一個正常人(不是開發者)的URL方案。所有網絡使用者已經習慣的這種方案稱example.com/login是您登錄的地方,而不是example.com/session/new。 因此,對於像登錄這樣的東西,轉移到REST url方案有什麼好處?只是爲了減輕開發人員理解和使用的負擔?我不明白這是如何以任何方式增強最終用戶的可讀性。 – 2010-07-25 02:09:34

+0

登錄的整個概念可以說是相當RESTless,因爲它引入了狀態的概念。我不認爲RESTfulness以這種特定的方式規定了URL模式,但是'/ login'仍然是一個非常好的URL *如果它符合你的目的*。我的意思是*一般*,堅持一個特定的模式是*好*爲人類的可讀性。正如你所說,'/ login'已經是一個可接受的模式,所以沒關係。 – deceze 2010-07-25 02:20:37

回答

1

Rest提供了另一個「約定優於配置」的塊。對於廣泛使用的,有限的一組常見問題(對整個模型的粗暴行爲),休息作爲應用程序開發慣例非常有用。

以這種方式標準化URL的好處究竟是什麼?

程序員效率。少思考;使更多的時間花在更難的問題上等。更好的可維護性。更簡單的測試。等

難道真的認爲不好的做法 開發現在使用 傳統路線網站?

是的,對於與模型的整個記錄​​進行交互的粗碎行爲。

此外,這些CRUD 行動應該能夠到 請求與任何類型 響應的請求,正在尋找回應。 所以相同的鏈接,比如說, 的例子。com/tasks也可以在example.com/tasks.xml調用 以獲得結果的xml 表示,或者獲取json 表示的012.example.com/tasks.json。

這是說,RESTful API 只是 網站上的常用鏈接,但附加了xml?

是的,如果你的API適合其餘模型。我認爲最大的問題是身份驗證。如果你希望你的api是無狀態的,那麼你可能需要在每次調用時都包含認證。此時,如果您不想使用HTTP級別身份驗證,則需要決定如何包含憑據。

+1

很好的答案。我想補充一點,擁有一個無狀態api(而不是需要表單,特別是隱藏字段,或者在cookie或服務器端會話存儲中的狀態)使書籤和腳本編寫變得相當容易。 – 2010-07-25 08:19:36

+1

克里斯托弗優秀點。我認爲提供對其服務的API訪問權限的人常常關注「重量級」API客戶端,而不是支持包括shell腳本在內的輕量級API客戶端。在每個API調用中啓用證書確實對後者有幫助。 – 2010-07-25 15:01:13