淺談REST API
說明： 本文部分內容根據其它網絡文章編寫，如有版權問題請及時通知。
背景
發跡於互聯網的REST，在國內國外混得可謂是風生水起，如今又進入電信行業的視野，連TMF都將其作為戰略項目Open Digital的一部分。
一種思維方式影響了軟件行業的發展。REST軟件架構是當今世界上最成功的互聯網的超媒體分布式系統。它讓人們真正理解我們的網絡協議HTTP本來面貌。它正在成為網絡服務的主流技術，同時也正在改變互聯網的網絡軟件開發的全新思維方式。
一、 REST API介紹
傳統上，軟件和網絡是兩個不同的領域，很少有交集；軟件開發主要針對單機環境，網絡則主要研究系統之間的通信。
互聯網的興起，使得這兩個領域開始融合，即 "互聯網軟件"，比網站、網絡游戲、各種非單機版APP等，
這種"互聯網軟件"采用客戶端/服務器（C/S）模式，建立在分布式體系上，通過互聯網通信，具有高延時（high latency）、高並發等特點。
那么如何開發在互聯網環境中使用的軟件呢？
RESTful架構，就是目前非常流行的一種互聯網軟件架構。
它結構清晰、符合標准、易於理解、擴展方便，所以正得到越來越多網站的采用。
但是，到底什么是RESTful架構，並不是一個容易說清楚的問題。下面，我就談談我理解的RESTful架構。
1、起源
REST 這個詞，是Roy Thomas Fielding在他2000年的博士論文中提出的。
Fielding是一個非常重要的人，他是HTTP協議（1.0版和1.1版）的主要設計者、Apache服務器軟件的作者之一、Apache基金會的第一任主席。
所以，他的這篇論文一經發表，就引起了關注，並且立即對互聯網開發產生了深遠的影響。
他這樣介紹論文的寫作目的：
本文研究計算機科學兩大前沿----軟件和網絡----的交叉點。長期以來，軟件研究主要關注軟件設計的分類、設計方法的演化，很少客觀地評估不同的設計選擇對系統行為的影響。而相反地，網絡研究主要關注系統之間通信行為的細節、如何改進特定通信機制的表現，常常忽視了一個事實，那就是改變應用程序的互動風格比改變互動協議，對整體表現有更大的影響。我這篇文章的寫作目的，就是想在符合架構原理的前提下，理解和評估以網絡為基礎的應用軟件的架構設計，得到一個功能強、性能好、適宜通信的架構。
(This dissertation explores a junction on the frontiers of two research disciplines in computer science: software and networking. Software research has long been concerned with the categorization of software designs and the development of design methodologies, but has rarely been able to objectively evaluate the impact of various design choices on system behavior. Networking research, in contrast, is focused on the details of generic communication behavior between systems and improving the performance of particular communication techniques, often ignoring the fact that changing the interaction style of an application can have more impact on performance than the communication protocols used for that interaction. My work is motivated by the desire to understand and evaluate the architectural design of network-based application software through principled use of architectural constraints, thereby obtaining the functional, performance, and social properties desired of an architecture. )
2、名稱
Fielding將他對互聯網軟件的架構原則，定名為REST，即Representational State Transfer的縮寫。我對這個詞組的翻譯是"表現層狀態轉化"。
如果一個架構符合REST原則，就稱它為RESTful架構。
要理解RESTful架構，最好的方法就是去理解Representational State Transfer這個詞組到底是什么意思，它的每一個詞代表了什么涵義。
如果你把這個名稱搞懂了，也就不難體會REST是一種什么樣的設計。
3、資源（Resources）
REST的名稱"表現層狀態轉化"中，省略了主語。"表現層"其實指的是"資源"（Resources）的"表現層"。
所謂"資源"，用在互聯網上就是網絡上的一個實體，或者說是網絡上的一個具體信息。它可以是一段文本、一張圖片、一首歌曲、一種服務，總之就是一個具體的實在。
用在OSS中”資源”就是eNodeB、小區、電路、基站退服告警、eUtranCell性能統計。
你可以用一個URI（統一資源定位符）指向它，每種資源對應一個特定的URI。
要獲取這個資源，訪問它的URI就可以，因此URI就成了每一個資源的地址或獨一無二的識別符。
所謂"上網"或者“運維”，就是與互聯網或OSS中一系列的"資源"互動，調用它的URI。
4、表現層（Representation）
"資源"是一種信息實體，它可以有多種外在表現形式。我們把"資源"具體呈現出來的形式，叫做它的"表現層"（Representation）。
比如，文本可以用txt格式表現，也可以用HTML格式、XML格式、JSON格式表現，甚至可以采用二進制格式；圖片可以用JPG格式表現，也可以用PNG格式表現。
URI只代表資源的實體，不代表它的形式。嚴格地說，有些網址最后的".html"后綴名是不必要的，因為這個后綴名表示格式，屬於"表現層"范疇，而URI應該只代表"資源"的位置。它的具體表現形式，應該在HTTP請求的頭信息中用Accept和Content-Type字段指定，這兩個字段才是對"表現層"的描述。
5、狀態轉化（State Transfer）
訪問一個網站，就代表了客戶端和服務器的一個互動過程。在這個過程中，勢必涉及到數據和狀態的變化。
互聯網通信協議HTTP協議，是一個無狀態協議。這意味着，所有的狀態都保存在服務器端。因此，如果客戶端想要操作服務器，必須通過某種手段，讓服務器端發生"狀態轉化"（State Transfer）。而這種轉化是建立在表現層之上的，所以就是"表現層狀態轉化"。
客戶端用到的手段，只能是HTTP協議。
具體來說，就是HTTP協議里面，四個表示操作方式的動詞：GET、POST、PUT、DELETE。
它們分別對應四種基本操作：GET用來獲取資源，POST用來新建資源（也可以用於更新資源），PUT用來更新資源，DELETE用來刪除資源。
6、綜述
綜合上面的解釋，我們總結一下什么是RESTful架構：
- 每一個URI代表一種資源；
- 客戶端和服務器之間，傳遞這種資源的某種表現層；
- 客戶端通過四個HTTP動詞（GET、POST、PUT和DELETE方法），對服務器端資源進行操作，實現"表現層狀態轉化"。
- 通過Representation（客戶端）來處理資源（服務器端）。也就是說，客戶端不能直接操作服務器端的資源，只能通過對相應的Representation的操作，並發送相應的請求，最后由服務器端來處理資源並返回結果。
- 客戶端和服務器端傳送的任何一個Message（消息），都應該是自描述的。也就是說處理這個Message所需要的上下文環境都應該包含在這個Message當中。
REST 從資源的角度來觀察整個網絡，分布在各處的資源由URI確定，而客戶端的應用通過URI來獲取資源的表征。獲得這些表征致使這些應用程序轉變了其狀態。隨着不斷獲取資源的表征，客戶端應用不斷地在轉變着其狀態，所謂表征狀態轉移（Representational State Transfer）。
這一觀點不是憑空臆造的，而是通過觀察當前Web互聯網的運作方式而抽象出來的。Roy Fielding 認為：
設計良好的網絡應用表現為一系列的網頁，這些網頁可以看作的虛擬的狀態機，用戶選擇這些鏈接導致下一網頁傳輸到用戶端展現給使用的人，而這正代表了狀態的轉變。
7、操作——增刪改查
需要注意的是，REST是設計風格而不是標准。REST通常基於使用HTTP，URI，和XML以及HTML這些現有的廣泛流行的協議和標准。
以eNodeB資源信息和告警信息為例：
HTTP 請求方法在RESTful Web 服務中的典型應用
| 資源 |
查詢 |
修改 |
增加 |
刪除 |
| GET |
PUT |
POST |
DELETE |
|
| 單個eNodeB的URI，比如http://net.chinamobile.com/resources/eNodeB/1001 |
獲取 名稱為1001的eNodeB資源詳細信息，格式可以自選一個合適的網絡媒體類型（比如：XML、JSON等） |
修改 名稱為1001的eNodeB資源信息。 |
創建一個新的名稱為1001的eNodeB資源。 |
刪除 名稱為1001的eNodeB資源數據。 |
| 一條告警信息的URI，比如http://net.chinamobile.com/alarms/123456789 |
獲取 告警標識為123456789的告警信息，格式可以自選一個合適的網絡媒體類型（比如：XML、JSON等），例如其它應用系統同步故障管理系統的某條告警或某類告警 |
修改告警標識為123456789的告警狀態，例如，用於當故障管理系統中告警的手工清除、確認、派單狀態、工單狀態、告警關聯關系等狀態變更時。 |
創建告警標識為123456789的告警，例如，用於故障管理系統向其它系統（如無線網優、業務監控、告警牌）送實時告警。 |
刪除告警標識為123456789的告警，例如，用於手工清除故障管理系統的告警。 |
二、 REST API的優點
- 可以利用緩存Cache來提高響應速度
- 通訊本身的無狀態性可以讓不同的服務器處理一系列請求中的不同請求，提高服務器的擴展性
- 瀏覽器即可做客戶端，簡化軟件開發的需求
- 相對於其他疊加的HTTP協議之上的機制，REST的軟件依賴性更小
- 不需要額外的資源發現機制
- 在軟件技術演進中的長期的兼容性更好
重點說一下什么是“無狀態”和“擴展性”。
1 在京東上選擇了一款華為榮耀6手機，並添加到購物車，然后又選擇了一款榮耀手環，也添加到購物車中，最后點擊結算按鈕，如果是京東網站采用了“無狀態”，那么，頁面不會呈現出您之前選擇的兩款產品信息及其價格。很簡單，這里的“購物車”實現了“有狀態”。
2 但REST API也可以實現有狀態，只需在URL里封裝購物車信息，或者為購物車創建另一個資源，比如“/carts/1234”。
3 REST API可以不需要與客戶端進行會話，通過這些操作（指在URL里封裝購物車信息，或者為購物車創建另一個資源，比如“/carts/1234”）后，客戶端向服務器發出請求后，哪怕你在服務器上執行卸載平台和操作系統、拆除服務器硬件、重新組裝服務器、重新安裝操作系統、平台、應用程序備份恢復操作，也不會影響客戶端。
4 REST之所以可以提高系統的可擴展性，就是因為它要求所有的操作都是無狀態的。由於沒有了上下文(Context)的約束，做分布式和集群的時候就更為簡單，也可以讓系統更為有效的利用緩沖池(Pool）。並且由於服務器端不需要記錄客戶端的一系列訪問，也減少了服務器端的負載。
三、 REST API與其它技術對比
讓我們來思考一下：
小明是瓜山村機房的資源管理員，該機房有1座鐵塔，2個天面，9根天線。小明現在模擬為一個REST API，而我是使用資源的應用客戶端。如果我想用REST來請求當前的機房狀態，我僅會問：“State？” 小明會回答：“1座鐵塔，2個天面，9根天線”。
這是REST最簡單的一個例子。小明使用表征來傳輸機房狀態。表征的句子很簡單：“1座鐵塔，2個天面，9根天線”。
再往下看，看我如何讓小明用REST方式添加2台eNodeB？
按照常理，可以會這樣說：小明，請在瓜山村機房添加2台eNodeB。難道這就是REST方式嗎？難道就是通過這樣的表征來傳輸狀態的嗎？不是的！這是一個遠程過程調用，過程是給瓜山村機房添加2台eNodeB。
小明很憤怒地響應到：“400，Bad Request”，你到底是什么意思？
所以，讓我們重新來一次。我們怎樣做到REST方式呢？該怎樣重新表征呢？好，讓我們再次重新表征……
我：“小明，……1座鐵塔，2個天面，9根天線，2台eNodeB！”
小明：“好的”。
我：“小明，現在是什么狀態？”
小明：“1座鐵塔，2個天面，9根天線，2台eNodeB！”。
我：“好！”
看到了嗎？就這樣簡單。
為什么RPC也不夠好？
從邏輯角度來看，為什么會更加青睞REST而不是RPC（Remote Procedure Call，遠程過程調用 ），因為它極大的降低了我們溝通的復雜度，通過把表征作為唯一的溝通的方式。無需去討論過程（添加一台BTS？增加一種傳輸設備？還是占用所有PTN端口？）我們只需討論表征，並且使用這個表征來達到我們想要的目標，很簡單，不是嗎？我不希望和小明的溝通失敗，因為我們彼此的理解過程會不一樣，所以只需要知道最后的狀態就行。但這僅僅是創建RPC會產生許多問題之一。
如果你使用RPC，你需要設計一些程序嵌入到某種結構中。這種結構需要存儲參數、錯誤的代碼、返回值等。我已經看到許多公司這樣做，他們設計自己的RPC-結構來實現客戶端與服務器端的交互，但卻產生許多問題。你為什么要這么做？為什么要創建自己的RPC-結構？這樣做的好處是？倘若我想要讓應用程序使用許多WebService，並且這些WebService帶有多個RPC-格式屬性？那么我不得不去開發一些類似這樣的東西：
如果你們真的需要RPC，至少要選擇一個類似SOAP的標准。
但SOAP也很糟糕
即使RPC的標准真的很令人痛苦，但我不得不承認ACID事務，一個完整的標准化服務描述性語言SOAP（Simple Object Access Protocol，簡單對象訪問協議）在某些環境下表現的還不錯。盡管如此，SOAP產品的性能開銷很大，它是一個巨大的性能殺手。雖然REST不是一個標准，但在實現RESTful Web服務時可以使用其他各種標准（比如HTTP、URL、XML、PNG等）。
REST是設計風格而不是標准：
REST可以說是一種與DO（分布式對象Distributed Objects）、RPC（遠程過程調用Remote Procedure Call）並列的架構體系，是一種設計分布式網絡服務或API時遵循的架構原則以及設計風格。
REST、DO、RPC之間區別對比
| REST |
DO |
RPC |
|
| 核心是資源，按資源建模 |
核心是對象，按對象建模 |
核心是過程，按過程建模 |
|
| 中立於開發平台和編程語言多種編程語言實現 |
通常與某種編程語言綁定的，跨語言交互實現復雜 |
雖然應用較廣泛，但跨語言交互實現復雜 |
|
| 沒有統一接口的概念，不同API接口設計風格不同 |
沒有統一接口的概念，不同API接口設計風格不同 |
||
| 統一接口 |
|||
| 使用超文本，交互效率比DO更高 |
沒有使用超文本，響應的內容中只包含對象本身 |
沒有使用超文本，響應的內容中只包含對象本身 |
|
| 三種風格中客戶端與服務器耦合度最小 |
帶來客戶端與服務器端的緊耦合。在三種架構風格之中DO風格的耦合度最大的 |
使用了平台中立的消息因而耦合度比DO風格要小，但比REST大 |
|
| 支持數據流和管道 |
不支持數據流和管道 |
不支持數據流和管道 |
REST與CORBA、SNMP、SOAP比較
| CORBA |
SNMP |
SOAP |
REST |
|
| 架構模式 |
面向對象 |
面向方法 |
面向方法 |
面向資源 |
| 統一的接口約束 |
無（CORBA服務可以任意添加方法） |
無（可以任意添加方法） |
無（可以任意添加方法） |
有（GET/PUT/ POST/DELETE） |
| 要求無狀態 |
否 |
否 |
否 |
是 |
| 消息體編碼格式 （編碼效率） |
二進制（高） |
二進制（高） |
XML（低） |
JSON（中） |
| 編譯耦合度 |
高（服務端和客戶端聯動編譯） |
低（解耦） |
低（解耦） |
低（解耦） |
| 傳輸協議（效率） |
TCP（高） |
UDP（高） |
HTTP（低） |
HTTP（低） |
| 在傳輸協議上封裝應用協議 |
是 |
是 |
是 |
否 |
| 跨語言能力 |
中 |
高 |
高 |
高 |
| 實現框架 |
重量級 |
輕量級 |
輕量級 |
羽量級 |
| 是否有歸一化的參考實現 |
有 |
有 |
有 |
無 |
| 原生支持負載均衡 |
否 |
否 |
否 |
是 |
| 原生支持失效轉發 |
否 |
否 |
否 |
是 |
| 原生支持事件通知 |
是 |
是 |
否 |
否 |
四、 REST API在互聯網中的應用
騰訊開放平台REST API導航圖：
下面是用戶信息類API“獲取用戶基本資料”的功能說明文檔。
1 功能說明
獲取登錄用戶的信息，包括昵稱、頭像、性別等信息。
本接口是全平台通用的，即發送請求后，可根據請求中傳入的“pf”平台參數返回對應平台的用戶信息，詳見返回字段說明。
例如：如果傳入的pf為qzone，則返回的是其QQ空間的昵稱和頭像。
注意：
1. 本接口返回的各種VIP（例如黃鑽等）信息是經過緩存的，有一定的延時。
如果需要VIP信息特別准確的場景（例如黃鑽每日禮包場景中，非黃鑽用戶開通黃鑽后，返回應用應該立即可領取禮包），請調用專門的VIP實時信息獲取接口。
目前為黃鑽提供專門的黃鑽實時信息獲取接口：v3/user/is_vip，其它VIP實時信息獲取接口為：v3/user/total_vip_info。
2. 本接口只返回用戶基本個人資料。對於其它更豐富的用戶個人資料，出於保護用戶隱私的考慮，目前尚不開放。
2 接口調用說明
2.1 URL
http://[域名]/v3/user/get_info
正式環境域名或測試環境IP詳見：API3.0文檔#請求URL說明。
2.2 格式
json
2.3 HTTP請求方式
GET, POST
2.4 IP限制
TRUE
2.5 輸入參數說明
各個參數請進行URL 編碼，編碼時請遵守 RFC 1738
（1）公共參數
發送請求時必須傳入公共參數，詳見公共參數說明。
（2）私有參數
| 參數名稱 |
是否必須 |
類型 |
描述 |
| charset |
string |
指定請求及響應的字符集，取值為gbk或utf-8（只有pf=qqgame或pf=3366時，可以輸入該參數）。 默認值為utf-8，其他非法取值也認為是utf-8。 |
|
| flag |
unsigned int |
pf=qqgame時，必須輸入該參數，指定需要獲取QQGame中的哪些信息： 1：需要獲取游戲昵稱和性別； |
2.6 請求示例
http://openapi.tencentyun.com/v3/user/get_info?
openid=B624064BA065E01CB73F835017FE96FA&
openkey=5F154D7D2751AEDC8527269006F290F70297B7E54667536C&
appid=2&
sig=VrN%2BTn5J%2Fg4IIo0egUdxq6%2B0otk%3D&
pf=qzone&
format=json&
userip=112.90.139.30
2.7 返回參數說明
| 參數名稱 |
描述 |
| ret |
返回碼。詳見公共返回碼說明#OpenAPI V3.0 返回碼。 |
| msg |
如果錯誤，返回錯誤信息。 |
| is_lost |
判斷是否有數據丟失。如果應用不使用cache，不需要關心此參數。 0或者不返回：沒有數據丟失，可以緩存。 |
| nickname |
昵稱。 |
| gender |
性別。 |
| country |
國家（當pf=qzone、pengyou或qplus時返回）。 |
| province |
省（當pf=qzone、pengyou或qplus時返回）。 |
| city |
市（當pf=qzone、pengyou或qplus時返回）。 |
| figureurl |
頭像URL。詳見：前端頁面規范#6. 關於用戶頭像的獲取和尺寸說明。 |
| openid |
用戶QQ號碼轉化得到的ID（當pf=qplus時返回）。 |
| qq_level |
用戶QQ等級（當pf=qplus時返回）。 |
| qq_vip_level |
用戶QQ會員等級（當pf=qplus時返回）。 |
| qplus_level |
用戶Q+等級（當pf=qplus時返回）。 |
| is_yellow_vip |
是否為黃鑽用戶（0：不是； 1：是）。 （當pf=qzone、pengyou或qplus時返回） |
| is_yellow_year_vip |
是否為年費黃鑽用戶（0：不是； 1：是）。 （當pf=qzone、pengyou或qplus時返回） |
| yellow_vip_level |
黃鑽等級，目前最高級別為黃鑽8級（如果是黃鑽用戶才返回此參數）。 （當pf=qzone、pengyou或qplus時返回） |
| is_yellow_high_vip |
是否為豪華版黃鑽用戶（0：不是； 1：是）。 （當pf=qzone、pengyou或qplus時返回） |
| is_blue_vip |
是否為藍鑽用戶（0：不是； 1：是）。 （當pf=qqgame或3366時返回） |
| is_blue_year_vip |
是否為年費藍鑽用戶（0：不是； 1：是）。 （當pf=qqgame或3366時返回） |
| blue_vip_level |
藍鑽等級（如果是藍鑽用戶才返回此參數）。 （當pf=qqgame或3366時返回） |
| 3366_level |
3366用戶的大等級。 （當pf=3366時返回） |
| 3366_level_name |
3366用戶的等級名，如小游游、小游仙。 （當pf=3366時返回） |
| 3366_grow_level |
3366用戶的成長等級。 （當pf=3366時返回） |
| 3366_grow_value |
3366用戶的成長值。 （當pf=3366時返回） |
| is_super_blue_vip |
是否是豪華藍鑽。 （當pf=qqgame或3366時返回） |
2.8 錯誤返回碼說明
公共錯誤返回碼：公共返回碼說明#OpenAPI V3.0 返回碼。
本接口私有錯誤返回碼：暫無。
2.9 正確返回示例
JSON示例:
Content-type: text/html; charset=utf-8
{
"ret":0,
"is_lost":0,
"nickname":"Peter",
"gender":"男",
"country":"中國",
"province":"廣東",
"city":"深圳",
"figureurl":"http://imgcache.qq.com/qzone_v4/client/userinfo_icon/1236153759.gif",
"is_yellow_vip":1,
"is_yellow_year_vip":1,
"yellow_vip_level":7,
"is_yellow_high_vip": 0
}
2.10 錯誤返回示例
Content-type: text/html; charset=utf-8
{
"ret":1002,
"msg":"請先登錄"
}
五、 REST API的設計
對於開發人員來說，關心的是如何使用REST架構，這里我們來簡單談談這個問題。REST不僅僅是一種嶄新的架構，它帶來的更是一種全新的Web開發過程中的思維方式：通過URL來設計系統結構。在REST中，所有的URL都對應着資源，只要URL的設計是良好的，那么其呈現的系統結構也就是良好的。這點和TDD(Test Driven Development)很相似，他是通過測試用例來設計系統的接口，每一個測試用例都表示一系列用戶的需求。開發人員不需要一開始就編寫功能，而只需要把需要實現的功能通過測試用例的形式表現出來即可。這個和REST中通過URL設計系統結構的方式類似，我們只需要根據需求設計出合理地URL，這些URL不一定非要鏈接到指定的頁面或者完成一些行為，只要它們能夠直觀的表現出系統的用戶接口。根據這些URL，我們就可以方便的設計系統結構。
從REST架構的概念上來看，所有能夠被抽象成資源的東西都可以被指定為一個URL，而開發人員所需要做的工作就是如何能把用戶需求抽象為資源，以及如何抽象的精確。因為對資源抽象的越為精確，對REST的應用來說就越好。這個和傳統MVC開發模式中基於Action的思想差別就非常大。設計良好的URL，不但對於開發人員來說可以更明確的認識系統結構，對使用者來說也方便記憶和識別資源，因為URL足夠簡單和有意義。按照以往的設計模式，很多URL后面都是一堆參數，對於使用者來說也是很不方便的。
來看下面這個簡單的采購方案例子：
可以看到，例子中定義了兩個服務程序（沒有包含任何實現細節）。這些服務程序的接口都是為了完成任務（正是我們討論的OrderManagement和CustomerManagement服務）而定制的。如果客戶端程序試圖使用這些服務，那它必須針對這些特定接口進行編碼——不可能在這些接口定義之前，使用客戶程序去有目的地和接口協作。這些接口定義了服務程序的應用協議（application protocol）。
在RESTful HTTP方式中，你將通過組成HTTP應用協議的通用接口訪問服務程序。你可能會想出像這樣的方式：
可以看到，服務程序中的特定操作被映射成為標准的HTTP方法。
六、 REST API的開發
1 REST Web Services框架 JAX-RS
JSR-311（JAX-RS: Java API for RESTful Web Service）是支持RESTful web服務的Java應用程序接口規范，它使用了Java SE 5引入的Java 標注來簡化Web服務客戶端和服務端的開發和部署。JAVA EE 6引入了對於JSR-311的支持。
以下是幾種JSR-311的實現：
- Oracle Jersey—— https://jersey.java.net/
- Jboss的RESTEasy——http://www.jboss.org/resteasy
- Apache的Wink——http://wink.apache.org/
- Spring MVC （Spring 3.0增加了對REST的支持）
2 REST Web Application多層框架
- JERSEY+ EJB3.0
- JERSEY 負責Web Service
- EJB3.0 負責管理bean的生命周期，都是stateless bean
- GUI端選擇其他方案或者富客戶端方案例如JS
- JERSEY+SPRING MVC
- JERSEY 負責Web Service
- SPRING 負責管理bean的生命周期
- GUI端用SPRING MVC或者其他富客戶端方案例如JS
- SPRING MVC
- SPRING MVC負責Web Service
- SPRING 負責管理bean的生命周期
- GUI端用SPRING MVC或者其他富客戶端方案例如JS
3 REST 應用場景
- 適合
- 無狀態的應用 stateless：判斷標准是服務器重啟不影響客戶端和服務端的交互。
- 緩存機制有利於解決頻繁訪問的性能問題。
- 客戶端和服務端互相了解。如果服務段是封閉的，並且接口描述是固定並記入合同，SOAP （on WSDL）更合適。
- REST WEB SERVICE更適合對於帶寬敏感的應用，適合富客戶端。
- 對於需要不斷開發新的WEB SERVICE並且需要集成到現有的應用里面，REST WEB SERVICE更合適。對於AJAX的應用，REST WEB SERVICE很容易集成。
- 不適合
- 如果軟件架構專注於非功能性需求，例如事務，安全性。很多業務超出了簡單的CRUD的操作，需要關聯上下文以及維護對話狀態，這種情況下如果還要用REST，就需要自己額外開發很多輔助功能。
- 異步處理和調用。