RESTful Rails 續 – HATEOS

以前曾經寫過一篇RESTful Rails 簡單心得,最近讀到一篇解釋RESTful的文章還不錯,就來補充一下吧

首先,根據Richardson Maturity Model,在完全的REST之前可以分成四種程度:

  1. The swamp of POX:單純的把HTTP當成RPC來用,沒有Resource的概念。譬如你要訂閱一份報紙,就會變成
    POST /subscribe_news?id=1234?type=free 之類的東西。

    此時每一個HTTP request都是單獨的action。

  2. Resource:顧名思義,API的設計開始以Resource為中心。同樣的訂閱報紙會變成:
    POST /news 先取得報紙列表,然後
    POST /subscription 建立「subscription」的resource

    此時,每個HTTP request都是針對某個Resource在操作,而不是一個複雜的動作

  3. HTTP verb:此時,你開始善用HTTP提供的get/post/put/delete,讓同樣的URL結合不同的HTTP verb來完成不同的動作。就如同舊文中Rails內建的resource一樣,不重複解釋。
  4. Hypermedia Control: 或是你可以叫做HATEOAS ( Hypertext As The Engine Of Application State )。
    還記得REST的全文:Representational State Transfer嗎?HATEOAS講的就是「Transfer」

    大多數的RESTful API,每個request都是對某種Resource獨立的操作。你要怎麼知道取得news id之後要建立 subscription來訂閱新聞?大多數的情況是:看文件。

    而Hypermedia Control的重點就是:你回傳的Resource中,必須要包含接下來可以做的事情的資訊。
    當你回傳一個news resource的時候,你還要附上訂閱該news所要使用的URL,顯示該news內容所需要的URL…等等。例如回傳的news可能會變成:

    { :title => "World War III!", :date => "2011/12/25", :subscribe => "/subscription", :show => "/news/123" }
    

    好處是什麼?好處是client只要取得news resource之後,就能清楚知道下一步所要用到的resource是什麼,而且這個「下一步」是可以隨著Server API變動而跟著改的,因此Client不需要寫死下一步的HTTP request該發什麼。也就是所謂的「Discoverability of Actions on a Resource」

至於為什麼很少人做到第四階段的REST?有人認為因為目前的工具並沒有方便的支援Hypermedia Control。或著也可以說,大多數人連POST跟GET都分不清楚了,搞的懂REST的也沒幾個,還有很長一段路要走呢…

Advertisements

RESTful Rails 續 – HATEOS” 有 1 則迴響

迴響已被關閉。