Log Day3 REST

最近翻了一下REST,
才發現原來我以前有整理過Wiki上面的REST資料:
http://chip.twbbs.org/2010/12/rest-part-1.html
http://chip.twbbs.org/2010/12/rest-part-2.html
http://chip.twbbs.org/2010/12/rest-part-3.html

哈哈... 難怪這篇文章念起來有一點熟悉...


Representational State Transfer (REST) 照字面上來說就是描述狀態的轉移,
其目標是描述分散式系統上可通用的軟體架構,

常寫軟體的人就很可以理解,
一個程式最基本就是控制資料與功能的進行,
以物件的觀點來看,
就是控制物件的狀態與行為(State and Behavior)

每種控制方法均有其目標,
REST的目標為:

• 元件互動間的可延展性 (Scalability of component interactions)
• 一般化的介面 (Generality of interfaces)
• 各元件可被獨立開發 (Independent deployment of components)
• 具有中介元件可以減少延遲, 增強安全性, 甚至將傳統的舊系統包裝起來相容新系統 (Intermediary components to reduce latency, enforce security and encapsulate legacy systems)

其中要達到這樣的目標, REST列出了必要的限制:

• Client–server
• Stateless
• Cacheable
• Layered System
• Code on demand (optional)
• Uniform interface

只要遵循以上的限制, 就符合REST架構風格, 也就可以有分散式超媒體系統(distributed hypermedia system)一些突出的特質如: performance, scalability, simplicity, modifiability, visibility, portability and reliability.

RESTful web service (也可稱為 RESTful web API) 是一個使用HTTP與REST的原理來實作的web service. 其為一個資源的集合, 裏頭包含了三個已定義的部分:

• web service所使用的基礎URI, (the base URI for the web service), 如: http://example.com/resources/
• web service所支援的資料MIME類型, 這邊泛指如 JSON, XML 或 YAML , 但也可是其他有效的MIME類型.
• web service所支援的操作集合, 這些操作使用HTTP的方法 (如: POST, GET, PUT 或 DELETE).
• 此API必須要基於超文字(hypertext)驅動為基礎

前三項可以理解, RESTful的服務必須符合Web的架構, 包括最重要的資源URI與資料型態, 甚至操作的方法都是符合Web, 當然為了是符合那六個限制, 以達到scalability, 甚至如現有網站的Open API可輕易的通用整合各項不同的服務.

最後一項是後來特別強調的, 因為有一些服務自己訂了一些API, 但裡面卻根本就是RPC骨子, 外面包了一層看起來像REST服務的介面, 輸出Web格式資料, 就稱自己為REST服務. (比如裡面根本不是Stateless也不Cacheable)

這種軟體架構的文章看太多就是會看越頭昏, 到最後反而有一點虛無飄渺... 尤其那句hypertext-driven, 連Fielding本人都寫了一篇文章來特別解釋: REST APIs must be hypertext-driven

回顧REST的諸多限制, 就是為了達到與凸顯分散式系統的好處而特別制定的軟體架構規範.
(應該這麼說: 假如你想要一個行為良好的分散式系統, 在設計時你就應該要這樣做...)