淺談REST API
淺談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，就需要自己額外開發很多輔助功能。
- 非同步處理和呼叫。