陳彥名

（中國(guó)移動(dòng)通信集團(tuán)設(shè)計(jì)院有限公司，北京 100080）

1 REST介紹

2000年，表述性狀態(tài)轉(zhuǎn)移（REpresentational State Transfer，REST）首 次 由Day Software公 司的首席科學(xué)家，Apach軟件基金會(huì)的合作創(chuàng)始人Roy Thomas Fielding博士在他的博士論文中提出。REST不是標(biāo)準(zhǔn)，而是架構(gòu)約束條件和原則，是一種設(shè)計(jì)風(fēng)格[1]。

Amazon公司在2002年推出了AWS云計(jì)算服務(wù)，在2006年3月，在A(yíng)WS中推出S3云存儲(chǔ)服務(wù)，S3的接口就是REST風(fēng)格的。S3獲得了成功，促進(jìn)了REST的普及[2]。而2008年前后的SOAP興起帶動(dòng)了REST和傳統(tǒng)Web服務(wù)方式（SOAP）的討論，REST風(fēng)格的API在互聯(lián)網(wǎng)領(lǐng)域開(kāi)始逐漸流行起來(lái)。2008年，JCP通過(guò)了JSR-311規(guī)范，提供了Java語(yǔ)言REST接口的參考規(guī)范， REST開(kāi)始大勢(shì)發(fā)展起來(lái)。

由于REST API非常適用于互聯(lián)網(wǎng)對(duì)用戶(hù)提供接口應(yīng)用，因此近年來(lái)得到了快速的發(fā)展。REST API當(dāng)前已經(jīng)是互聯(lián)網(wǎng)應(yīng)用的主流API風(fēng)格，國(guó)內(nèi)外知名網(wǎng)站大多提供了開(kāi)放的REST API供用戶(hù)重開(kāi)發(fā)。

互聯(lián)網(wǎng)采用REST API的主要原因如下：

（1） 互聯(lián)網(wǎng)中存在大量的資源；

（2） 各種資源可滿(mǎn)足無(wú)狀態(tài)特征；

（3） 大部分資源能通過(guò)URI來(lái)表達(dá)；

（4） 互聯(lián)網(wǎng)水平擴(kuò)展性極強(qiáng)；

（5） 用戶(hù)可利用API返回的內(nèi)容進(jìn)行二次開(kāi)發(fā)；

（6） 用戶(hù)可隨時(shí)、隨地對(duì)內(nèi)容資源進(jìn)行訪(fǎng)問(wèn)；

（7） 通過(guò)HTTP協(xié)議保證用戶(hù)使用的安全性。

目前，國(guó)外開(kāi)放的REST API產(chǎn)品有Google產(chǎn)品，如Google翻譯，Google BigQuery，Google眼鏡等；Amazon.com提供的一系列REST API，比較著名的有Amazon云服務(wù)S3的API接口；Twitter。國(guó)內(nèi)著名互聯(lián)網(wǎng)平臺(tái)開(kāi)放的REST API有新浪微博；淘寶、騰訊、百度云、移動(dòng)微博的REST API開(kāi)放平臺(tái)等。

TM Forum（全球電信管理論壇）是一個(gè)非盈利性組織，宗旨是領(lǐng)導(dǎo)服務(wù)供應(yīng)商在通信、媒體和云服務(wù)市場(chǎng)提供最好的IT，幫助行業(yè)建立、交換和收益于數(shù)字服務(wù)，其他成員來(lái)自195個(gè)國(guó)家700組織和公司，很多成員都來(lái)自傳統(tǒng)的電信運(yùn)營(yíng)商和設(shè)備商，最近也發(fā)起了云服務(wù)策略，期望行業(yè)在基于云服務(wù)的市場(chǎng)里克服一些阻力以實(shí)現(xiàn)云服務(wù)增長(zhǎng)。該組織提出了REST API可用于“多云服務(wù)管理計(jì)劃”中的“簡(jiǎn)單管理API”項(xiàng)目，多云服務(wù)即依靠多個(gè)云平臺(tái)承載某項(xiàng)服務(wù)，在其簡(jiǎn)單管理API定義REST風(fēng)格架構(gòu)為云平臺(tái)與云平臺(tái)之間，云平臺(tái)與終端之間提供一套完善且標(biāo)準(zhǔn)化的管理接口，從而實(shí)現(xiàn)跨平臺(tái)的無(wú)縫服務(wù)。

2 Rest技術(shù)概要

2.1 設(shè)計(jì)概念及準(zhǔn)則

REST 從資源的角度來(lái)觀(guān)察整個(gè)網(wǎng)絡(luò)，分布在各處的資源由URI確定，而客戶(hù)端的應(yīng)用通過(guò)URI來(lái)獲取資源的表示方式。獲得這些表徵致使這些應(yīng)用程序轉(zhuǎn)變了其狀態(tài)。隨著不斷獲取資源的表示方式，客戶(hù)端應(yīng)用不斷地在轉(zhuǎn)變著其狀態(tài)，所謂表述性狀態(tài)轉(zhuǎn)移（REpresentational State Transfer)[3]。例如，在移動(dòng)通信網(wǎng)絡(luò)管理的統(tǒng)計(jì)指標(biāo)中，“下載流量最多的前n位客戶(hù)”和“使用4G流量最多的n位用戶(hù)”在數(shù)據(jù)上可能是重疊或者完全相同的，但由于他們的表現(xiàn)形式不同，所以被歸為不同的資源，每個(gè)資源對(duì)應(yīng)一個(gè)唯一的資源標(biāo)識(shí)符（Uniform Resource Identifier，URI）。因此，當(dāng)網(wǎng)絡(luò)管理員希望獲取“下載流量最大的前n個(gè)用戶(hù)”時(shí)，輸入U(xiǎn)RI1獲取相應(yīng)的資源，當(dāng)其希望得到“使用4G流量最多的n位用戶(hù)”時(shí)，輸入U(xiǎn)RI2獲取相應(yīng)的資源。由于URI的編寫(xiě)方式是獨(dú)一無(wú)二的，因此資源也就具有唯一性，被用戶(hù)使用唯一的途徑進(jìn)行訪(fǎng)問(wèn)，如圖1所示。

圖1 REST中資源的概念

REST采用URI對(duì)資源進(jìn)行訪(fǎng)問(wèn)，每個(gè)URI都能夠使用以下7種HTTP方法：GET/POST/PUT/DELETE/PATCH/HEAD/OPTIONS，對(duì)應(yīng)增刪改查等操作[1]。

而使用REST的另一個(gè)奇妙之處在于它的狀態(tài)表述轉(zhuǎn)移特點(diǎn)，如上所述，每個(gè)對(duì)象都被當(dāng)作資源，當(dāng)這些資源分布在不同的邏輯和物理區(qū)域時(shí)，依然能通過(guò)唯一的URI被訪(fǎng)問(wèn)。這些資源就是“狀態(tài)”，這樣，互聯(lián)網(wǎng)就是一個(gè)巨大的狀態(tài)機(jī)：每個(gè)網(wǎng)頁(yè)是它的一個(gè)狀態(tài)；URI是這些狀態(tài)的表述方式；REST風(fēng)格的應(yīng)用則是從一個(gè)狀態(tài)遷移到下一個(gè)狀態(tài)的狀態(tài)轉(zhuǎn)移過(guò)程[1]。

最后，REST風(fēng)格的無(wú)狀態(tài)服務(wù)器特點(diǎn)使得在狀態(tài)遷移的過(guò)程中，服務(wù)器不需要記錄任何Session，所有的狀態(tài)都通過(guò)URL的形式記錄在了客戶(hù)端。對(duì)資源的各種操作都不會(huì)改變資源標(biāo)識(shí)。

2.2 性能及安全分析

大多數(shù)瀏覽器、HTTP服務(wù)器對(duì)于URL的長(zhǎng)度都是有限制的，因此REST API一般不能傳遞過(guò)于復(fù)雜的參數(shù)。從響應(yīng)速度來(lái)看，REST方式API服務(wù)端往往會(huì)采取多實(shí)例來(lái)實(shí)現(xiàn)處理能力的水平擴(kuò)展，其負(fù)載均衡過(guò)程中，會(huì)加大一次請(qǐng)求的操作延時(shí)。但是目前可以利用緩存Cache來(lái)提高響應(yīng)速度，通過(guò)“客戶(hù)端”使用“緩存”下來(lái)的數(shù)據(jù)，減少“客戶(hù)端”和“服務(wù)器”端的交互次數(shù)，從而達(dá)到提高網(wǎng)絡(luò)性能的目的。

以Amazon S3提供的REST API為例，其設(shè)計(jì)目標(biāo)是時(shí)延小于300 ms，而用戶(hù)實(shí)測(cè)一般處于200 ms到300ms之間。由于A(yíng)mazon同時(shí)提供了基于REST的和基于SOAP的Web服務(wù), 因此他們做了兩者速度的比較，據(jù)Amazon宣稱(chēng)，REST風(fēng)格的Web服務(wù)比基于SOAP的快6倍。

從安全性角度來(lái)進(jìn)行分析，目前沒(méi)有專(zhuān)門(mén)針對(duì)REST的特定安全規(guī)范，但REST可以使用HTTP協(xié)議的所有安全方式 ，REST API基于HTTP協(xié)議，可提供如下安全方式：

（1） 用戶(hù)名/口令（防止非授權(quán)訪(fǎng)問(wèn)）；

（2） SSL通信（防止中間人攻擊）；

（3） 消息體摘要（防抵賴(lài)）；

（4） 直接應(yīng)用其它WEB安全協(xié)議、鑒權(quán)、認(rèn)證。

以目前世界規(guī)模最大的亞馬遜Web云計(jì)算服務(wù)為例，其基于REST方式的接口模式尚無(wú)安全問(wèn)題出現(xiàn)，而目前，淘寶、新浪等都開(kāi)放了REST接口，也尚無(wú)安全問(wèn)題。當(dāng)然，黑客技術(shù)也在不斷發(fā)展，安全問(wèn)題長(zhǎng)期存在，REST技術(shù)也會(huì)不斷前進(jìn)，在競(jìng)爭(zhēng)中不斷發(fā)展起來(lái)。

2.3 Rest與基于SOAP 的Webservice技術(shù)比較

目前，最流行的兩種主流Webservice方式分別為基于SOAP的和基于REST的，從流行程度而言，SOAP流行已久，業(yè)界有很多較成熟的應(yīng)用，而REST API為后起之秀，正在受到廣泛關(guān)注。API聚合網(wǎng)站ProgrammableWeb對(duì)比了該網(wǎng)站上2008年和2010年各種不同的API協(xié)議部署量，2008年對(duì)REST關(guān)注度為60%，對(duì)SOAP的關(guān)注度為25%；到2010年，對(duì)REST的關(guān)注度為74%，對(duì)SOAP的關(guān)注度為15%。

從協(xié)議上而言，SOAP僅使用HTTP的POST方法傳輸封裝好的XML文件，用UDDI進(jìn)行服務(wù)注冊(cè)和搜索，用WSDL描述如何使用SOAP來(lái)調(diào)用Web服務(wù)。REST直接將HTTP作為應(yīng)用協(xié)議，也是HTTP協(xié)議設(shè)計(jì)的初衷。SOAP學(xué)習(xí)成本高，開(kāi)發(fā)難度大，加之協(xié)議隨著需求增加而不斷擴(kuò)充，其并發(fā)性能下降，但SOAP已經(jīng)得到廣泛的部署，且穩(wěn)健性較好。REST目前主要針對(duì)大量的Web 2.0網(wǎng)站使用，高效以及簡(jiǎn)潔易用，處于發(fā)展趨勢(shì)種。

圖2為REST和SOAP的對(duì)比圖，分別從風(fēng)格、定義、資源、URI、數(shù)據(jù)響應(yīng)模型等多方面對(duì)這兩種方式進(jìn)行了對(duì)比，各有各的優(yōu)勢(shì)，只是REST的易擴(kuò)展性符合了Web 2.0的發(fā)展，也最佳的匹配了目前云計(jì)算的發(fā)展方向，因此越來(lái)越得到設(shè)計(jì)者們的認(rèn)可。

圖2 REST和SOAP技術(shù)對(duì)比圖

3 REST移動(dòng)通信網(wǎng)絡(luò)管理中的應(yīng)用

根據(jù)REST適用場(chǎng)景，可以分析REST在移動(dòng)通信網(wǎng)絡(luò)管理中的應(yīng)用場(chǎng)景。一是適用于第三方集成商做二次開(kāi)發(fā)，例如目前互聯(lián)網(wǎng)開(kāi)放API多被用戶(hù)（第三方）利用來(lái)進(jìn)行二次開(kāi)發(fā)，二是REST API非常適合云計(jì)算類(lèi)環(huán)境。這是因?yàn)閃eb應(yīng)用程序最重要的 REST原則是，客戶(hù)端和服務(wù)器之間的交互在請(qǐng)求之間是無(wú)狀態(tài)的；從客戶(hù)端到服務(wù)器的每個(gè)請(qǐng)求都必須包含理解請(qǐng)求所必需的信息。如果服務(wù)器在請(qǐng)求之間的任何時(shí)間點(diǎn)重啟，客戶(hù)端不會(huì)得到通知，無(wú)狀態(tài)請(qǐng)求可以由任何可用服務(wù)器回答；客戶(hù)端可以緩存數(shù)據(jù)以改進(jìn)性能。因此，我們可以分析在移動(dòng)通信網(wǎng)絡(luò)管理中，REST能提供如下幾種應(yīng)用場(chǎng)景。

3.1 移動(dòng)通信網(wǎng)絡(luò)管理模塊內(nèi)部的接口調(diào)用

根據(jù)REST的特點(diǎn)，針對(duì)非實(shí)時(shí)性、擴(kuò)展性要求較高的應(yīng)用，可建議采用REST API接口方式。而在大數(shù)據(jù)時(shí)代，移動(dòng)通信的用戶(hù)數(shù)和用量越來(lái)越龐大，少量存儲(chǔ)設(shè)備已經(jīng)不能很好的滿(mǎn)足現(xiàn)網(wǎng)需求，并且，網(wǎng)絡(luò)容量的擴(kuò)張也往往超出預(yù)想，如性能管理系統(tǒng)由于存儲(chǔ)、處理、上報(bào)海量的性能數(shù)據(jù)，要求時(shí)延較小、可擴(kuò)展性強(qiáng)，可采用REST API進(jìn)行接口實(shí)現(xiàn)，完成各項(xiàng)合適的功能，例如號(hào)碼跟蹤、投訴/故障查詢(xún)、用戶(hù)記錄鉆取查詢(xún)等功能，見(jiàn)表1所示。

表1 性能管理系統(tǒng)內(nèi)部建議REST API舉例

3.2 網(wǎng)絡(luò)管理模塊之間的接口調(diào)用

在移動(dòng)通信網(wǎng)絡(luò)管理中，不同管理系統(tǒng)模塊之間也經(jīng)常性存在數(shù)據(jù)和信息交互，例如，資源管理系統(tǒng)在執(zhí)行網(wǎng)絡(luò)資源調(diào)度或業(yè)務(wù)資源開(kāi)通等作業(yè)時(shí)，就經(jīng)常用到性能管理系統(tǒng)模塊內(nèi)的性能數(shù)據(jù)，而資源管理系統(tǒng)對(duì)實(shí)時(shí)性要求并不強(qiáng)烈，不需要在秒級(jí)范圍內(nèi)得到性能系統(tǒng)提供的數(shù)據(jù)，因此這兩種模塊間也可以采用REST API接口進(jìn)行內(nèi)容交互，如圖3所示。但是，REST并不支持事件通知，不適用上報(bào)告警，因此，不適用于與告警模塊的交互。目前，已經(jīng)有部分廠(chǎng)家成功采用了REST API方式實(shí)現(xiàn)模塊間的資源調(diào)用。

圖3 移動(dòng)通信網(wǎng)絡(luò)管理模塊間采用REST API方式進(jìn)行交互

3.3 移動(dòng)網(wǎng)絡(luò)管理模塊向外部提供APP應(yīng)用采用REST API方式

例如，在進(jìn)行客服端、記賬平臺(tái)、采購(gòu)、營(yíng)銷(xiāo)策略分析APP開(kāi)發(fā)時(shí)，可以采用REST API方式進(jìn)行（如圖4所示），既保證了任何位置的數(shù)據(jù)都隨時(shí)方便的被獲取，又保證了提供這些APP應(yīng)用的數(shù)據(jù)可以隨時(shí)更替、變換、擴(kuò)展。

圖4 移動(dòng)通信模塊向外部提供應(yīng)用時(shí)采用REST API方式

4 總結(jié)

REST作為一種正在新興發(fā)展的技術(shù)，正處在蓬勃向上的過(guò)程中，其優(yōu)點(diǎn)很多，例如，該方式可以利用緩存Cache來(lái)提高響應(yīng)速度，具有較好的水平擴(kuò)展性，瀏覽器即可做客戶(hù)端，簡(jiǎn)化軟件開(kāi)發(fā)的需求，相對(duì)于其他疊加的HTTP協(xié)議之上的機(jī)制，REST的軟件依賴(lài)性更小，并且在軟件技術(shù)演進(jìn)中的長(zhǎng)期的兼容性更好。這些優(yōu)點(diǎn)這使得REST風(fēng)格在對(duì)應(yīng)云計(jì)算、大數(shù)據(jù)技術(shù)表現(xiàn)出了強(qiáng)有力的優(yōu)勢(shì)，在移動(dòng)通信行業(yè)現(xiàn)階段積極采用云計(jì)算模式進(jìn)行架構(gòu)和資源設(shè)計(jì)的情況下，在目前大數(shù)據(jù)的呼聲越來(lái)越高漲的環(huán)境下，REST風(fēng)格無(wú)疑是順應(yīng)這一趨勢(shì)的最佳選擇。

但是，任何事物都有兩面性，REST的發(fā)展也受到了很大的約束，例如，對(duì)于老系統(tǒng)改造來(lái)說(shuō)，全面切換到REST風(fēng)格工作量巨大，并且REST不支持事件通知，使得實(shí)時(shí)告警等需求不能完成，需要通過(guò)客戶(hù)端輪詢(xún)來(lái)模擬事件通知。另外，目前的REST還缺少比較強(qiáng)力的參考實(shí)現(xiàn)，與其它Web技術(shù)比較，例如SOAP來(lái)說(shuō)，也沒(méi)有絕對(duì)的優(yōu)勢(shì)，要求使用者分場(chǎng)景、分需求的來(lái)進(jìn)行技術(shù)選擇。因此，在移動(dòng)通信網(wǎng)絡(luò)管理中采用該技術(shù)時(shí)，應(yīng)該順勢(shì)而為且與其它技術(shù)一起結(jié)合取長(zhǎng)補(bǔ)短，搜索和分析業(yè)界已有成功案例，最好是在新建系統(tǒng)中采用該技術(shù)，而不是大規(guī)模改造舊系統(tǒng)，由此帶來(lái)的效益和性?xún)r(jià)比才能達(dá)到最好。

[1]Jim Webber, Savas Parastatidis, Ian Robinson.REST in practice[M].Carlifornia：O'Reilly Media, 2010:12.

[2]唐京偉.基于云計(jì)算的分布式存儲(chǔ)技術(shù)[J].中國(guó)傳媒科技, 2013（15):21.

[3]Thomas Erl, Benjamin Carlyle, Cesare Pautasso, Raj Balasubramanian.馬國(guó)耀, 等, 譯.SOA與REST：用REST構(gòu)建企業(yè)級(jí)SOA解決方案[M].北京：人民郵電出版社, 2013:43-56.