趙啟升，李存華，吳庚午，劉小明

(1.淮海工學(xué)院計(jì)算機(jī)工程學(xué)院，江蘇連云港222005)(2.淮海工學(xué)院信息中心，江蘇 連云港222005)

隨著移動(dòng)互聯(lián)網(wǎng)的快速發(fā)展，教育領(lǐng)域的教學(xué)模式、學(xué)習(xí)方式也逐漸發(fā)生變化.傳統(tǒng)的Web應(yīng)用正逐步被Android，iOS等智能手機(jī)APP所取代，越來越多的開發(fā)者開始關(guān)注高校APP的開發(fā).但是由于高校內(nèi)各教務(wù)系統(tǒng)平臺(tái)不統(tǒng)一，數(shù)據(jù)模型不兼容，校園APP的開發(fā)難度較大.設(shè)計(jì)并實(shí)現(xiàn)一個(gè)用于整合高校內(nèi)各教務(wù)系統(tǒng)資源，為開發(fā)者提供統(tǒng)一API的數(shù)據(jù)開放平臺(tái)就顯得尤為重要［1］.

1 RESTful Web Service介紹

表現(xiàn)層狀態(tài)轉(zhuǎn)移(representational state transfer，REST)是Roy Fielding博士在2000年提出來的一種軟件風(fēng)格架構(gòu)，根據(jù)REST原則，RESTful架構(gòu)的系統(tǒng)平臺(tái)將數(shù)據(jù)抽象成資源，通過通用資源標(biāo)識(shí)符(uniform resource identifier，URI)來標(biāo)識(shí)數(shù)據(jù)資源的唯一性.與傳統(tǒng)的SOAP Web Service架構(gòu)相比，REST風(fēng)格架構(gòu)的Web Service使得用戶僅僅通過訪問URI就可以獲取相應(yīng)的數(shù)據(jù)資源，并通過HTTP協(xié)議的簡單動(dòng)作就能完成對資源的操作［2］.

一個(gè)符合REST原則的服務(wù)架構(gòu)就稱其為RESTful架構(gòu).REST原則主要有3個(gè)概念:資源(resources)、表現(xiàn)層(representation)以及狀態(tài)轉(zhuǎn)化(state transfer).只有清楚理解這3個(gè)概念，才能設(shè)計(jì)出嚴(yán)格符合REST風(fēng)格的架構(gòu)［4］.

1)資源:表現(xiàn)層狀態(tài)轉(zhuǎn)化是資源表現(xiàn)層狀態(tài)轉(zhuǎn)化，因?yàn)楹拖到y(tǒng)交互的是網(wǎng)絡(luò)上一個(gè)具體存在的實(shí)體，或者說是一個(gè)具體的信息體.系統(tǒng)通過URI指向某個(gè)具體的資源，并與之交互.URI就是資源的唯一標(biāo)識(shí)符.

2)表現(xiàn)層:URI只代表具體的資源，而資源的呈現(xiàn)方式就是表現(xiàn)層.表現(xiàn)層是資源具體表現(xiàn)格式的體現(xiàn)，比如XML格式、JSON格式等.這具體由HTTP協(xié)議信息頭的Accept和Content－Type字段來指定.

3)狀態(tài)轉(zhuǎn)化:互聯(lián)網(wǎng)通信協(xié)議HTTP協(xié)議是一個(gè)無狀態(tài)的協(xié)議(事務(wù)處理沒有記憶能力，每一次請求都是與之前請求毫無關(guān)系的獨(dú)立事務(wù))，通過HTTP協(xié)議提供的4個(gè)動(dòng)作:GET/PUT/DELETE/POST來實(shí)現(xiàn)資源的狀態(tài)轉(zhuǎn)化［3］.REST架構(gòu)如圖1.

圖1REST架構(gòu)Fig.1 Architecture diagram of REST

1.1 RPC風(fēng)格與REST風(fēng)格比較

RPC風(fēng)格的Web Service服務(wù)器通常會(huì)從客戶端收到一個(gè)數(shù)據(jù)信封，然后處理，完成之后再向客戶端返回一個(gè)數(shù)據(jù)信封.這種方式使得服務(wù)器無法通過URI來標(biāo)識(shí)資源，客戶端也無法利用HTTP的特性來操作資源.由于客戶端和服務(wù)器的交互基本都是基于HTTP的，所以RPC風(fēng)格的Web Service在空間信息共享和互操作上還存在很多問題.

相比之下，REST風(fēng)格架構(gòu)從設(shè)計(jì)之初就已經(jīng)解決了這些問題，它是一種面向資源的架構(gòu).REST通過URI標(biāo)識(shí)了資源的唯一性，并且只需HTTP請求動(dòng)作就能實(shí)現(xiàn)對于資源的操作.REST風(fēng)格架構(gòu)有更強(qiáng)的伸縮性和交互能力.

1.2 REST架構(gòu)的設(shè)計(jì)與實(shí)現(xiàn)

1.2.1 URI設(shè)計(jì)

一個(gè)合理的URI設(shè)計(jì)就是一個(gè)良好的系統(tǒng)架構(gòu)，因?yàn)镽EST允許通過URI設(shè)計(jì)系統(tǒng)，所以在實(shí)現(xiàn)REST架構(gòu)的時(shí)候，首要考慮的就是如何設(shè)計(jì)一個(gè)合理的URI.REST架構(gòu)主要用于為開發(fā)者提供API，因此在設(shè)計(jì)URI的時(shí)候還需要加入API的版本號(hào).此外，URI中只能有名詞，這些名詞往往與數(shù)據(jù)庫中的表名相對應(yīng)，URI中還需要相應(yīng)的參數(shù)來過濾結(jié)果.URI格式如圖2.

圖2 URI圖示Fig.2 URI Icon

1.2.2 URI重寫

URI是服務(wù)器資源的身份標(biāo)識(shí)，它是唯一的.但是服務(wù)器并不直接處理該URI.服務(wù)器的重寫規(guī)則可將URI轉(zhuǎn)換成服務(wù)器能夠識(shí)別的有效URL，在實(shí)現(xiàn)REST架構(gòu)時(shí)，重寫URI是必要的過程［5］.

1.2.3 狀態(tài)碼設(shè)計(jì)

對于客戶端的請求，服務(wù)器處理完成之后會(huì)返回?cái)?shù)據(jù)結(jié)果和狀態(tài)碼，狀態(tài)碼用于標(biāo)識(shí)服務(wù)器的每一次處理狀態(tài).常見狀態(tài)碼及其含義如表1.

表1 狀態(tài)碼Table 1 Status code

2 Web Service系統(tǒng)框架介紹

框架的作用主要是提高程序的可重用性，將業(yè)務(wù)邏輯和具體實(shí)現(xiàn)相互分離，為APP開發(fā)人員提供一個(gè)易擴(kuò)展、易維護(hù)、高效穩(wěn)定的應(yīng)用程序骨架.依據(jù)Web Service的具體需求，文中實(shí)現(xiàn)的系統(tǒng)框架需要用于接口請求驗(yàn)證的authentication模塊、管理系統(tǒng)緩存的Cache管理模塊、配置和加載具體模塊方法的route模塊、用于數(shù)據(jù)格式化輸出的Parse模塊以及負(fù)責(zé)數(shù)據(jù)庫操作的DAO模塊［6］.

1)DAO數(shù)據(jù)庫訪問抽象層，本文將數(shù)據(jù)庫連接和數(shù)據(jù)庫基本操作封裝在DAO層中，每一個(gè)實(shí)體對象都繼承了該DAO層，通過集成和重寫DAO層的方法與數(shù)據(jù)庫進(jìn)行交互，實(shí)現(xiàn)數(shù)據(jù)庫的基本操作.這樣也使得底層的數(shù)據(jù)庫操作與業(yè)務(wù)邏輯分離，降低了框架的耦合性［7－8］.

2)parser層，位于DAO層之上，該層將數(shù)據(jù)封裝格式化為指定的格式或?qū)ο?，然后交由指定的服?wù)模塊處理，系統(tǒng)處理之后的結(jié)果也由該模塊打包成指定格式并返回給客戶端.

3)cache management，文中實(shí)現(xiàn)系統(tǒng)中的緩存管理主要有Session緩存和文件緩存兩種形式，session緩存用來存儲(chǔ)用戶基本信息和基本校驗(yàn)數(shù)據(jù).它比文件緩存和數(shù)據(jù)庫操作更高效，很適合在頻繁調(diào)用數(shù)據(jù)的時(shí)候使用.文件緩存用于保存本系統(tǒng)的臨時(shí)查詢和處理結(jié)果，所有的緩存都有相應(yīng)的回收策略，在一定時(shí)間之后會(huì)自動(dòng)更新緩存數(shù)據(jù).

4)authenticate認(rèn)證機(jī)制，為確保API接口調(diào)用的合法性，本系統(tǒng)設(shè)計(jì)了相應(yīng)的驗(yàn)證機(jī)制，用于校驗(yàn)用戶請求的合法性.本系統(tǒng)主要通過用戶注冊時(shí)提供的設(shè)備IMEI來校驗(yàn)用戶請求的合法性.

3 Web Service系統(tǒng)框架實(shí)現(xiàn)

文中實(shí)現(xiàn)系統(tǒng)框架的執(zhí)行流程:對于每一個(gè)API請求，系統(tǒng)都會(huì)對其進(jìn)行合法性驗(yàn)證，驗(yàn)證不通過，則返回請求失敗的信息到客戶端;如果通過驗(yàn)證，系統(tǒng)執(zhí)行框架的路由模塊，路由模塊根據(jù)請求URL加載相應(yīng)的模塊和方法，系統(tǒng)將結(jié)果數(shù)據(jù)處理成統(tǒng)一的格式后返回給客戶端，整個(gè)流程到此執(zhí)行完畢.

3.1 請求驗(yàn)證層實(shí)現(xiàn)

請求驗(yàn)證層主要負(fù)責(zé)對每一次用戶請求進(jìn)行驗(yàn)證，可通過Authentic類實(shí)現(xiàn).其中，authBySession方法通過session緩存來獲取用戶IMEI進(jìn)行校驗(yàn)，authByDb方法通過數(shù)據(jù)庫校驗(yàn)用戶的合法IMEI.authByIP方法校驗(yàn)用戶IP，主要用于一些有IP限制的接口.authByRequestNum方法用于限制用戶的請求次數(shù)，這主要針對像通知這類請求比較頻繁的接口.RequestAuth類繼承了Authentic類，其方法requestCheck是根據(jù)父類給出的校驗(yàn)方法制定校驗(yàn)規(guī)則，從而實(shí)現(xiàn)整個(gè)校驗(yàn)流程，postDataValidate方法是對每個(gè)接口所提交的參數(shù)進(jìn)行合法性檢查.類圖如圖3所示.

圖3 請求驗(yàn)證層類Fig.3 Class diagram of request validation layer

3.2 路由和緩存管理層實(shí)現(xiàn)

路由和緩存管理層主要設(shè)定緩存管理機(jī)制和路由加載機(jī)制，緩存管理用于管理用戶的請求數(shù)據(jù)緩存，路由加載用于加載和配置框架具體執(zhí)行的模塊和方法.以session緩存管理為例，在緩存管理模塊中，sessionCache類通過繼承父類Cache來重寫父類的方法，從而完成整個(gè)緩存管理機(jī)制.其中父類中定義了讀取緩存，寫入緩存和判斷過期時(shí)間3個(gè)基本方法.其類圖如圖4.

3.3 解析層實(shí)現(xiàn)

解析層主要實(shí)現(xiàn)框架的網(wǎng)頁解析功能和數(shù)據(jù)格式化.Curl類定義了網(wǎng)頁解析功能的集體實(shí)現(xiàn)，HttpCurl類通過繼承Curl父類，重載父類的curl方法，實(shí)現(xiàn)按照不同的情況解析網(wǎng)頁的功能，Parser類定義了網(wǎng)頁解析之后數(shù)據(jù)處理的常用方法和數(shù)據(jù)返回格式化的常用操作.其類圖如圖5.

圖4 緩存管理類Fig.4 Class diagram of cache management

圖5 解析層類Fig.5 Class diagram of analytical layer

4 系統(tǒng)運(yùn)行測試與分析

本系統(tǒng)的運(yùn)行環(huán)境為Windows Server 2008，IIS版本為7.5，數(shù)據(jù)庫版本為MySQL 5.5，Oracle 11g，網(wǎng)絡(luò)環(huán)境為電信100Mbps，PHP版本為5.4.進(jìn)行系統(tǒng)測試的目的是檢查系統(tǒng)框架基礎(chǔ)模塊能否正確運(yùn)行和系統(tǒng)接口是否符合REST原則.本系統(tǒng)所做測試主要以APP開發(fā)者用戶的身份測試:測試系統(tǒng)的用戶基本信息查詢和成績查詢接口.開發(fā)者用戶主要通過系統(tǒng)提供的接口URI來調(diào)用相關(guān)數(shù)據(jù)，該URI不僅包含了調(diào)用的資源和返回的格式，而且還定義了調(diào)用資源的動(dòng)作(增、刪、改、查).本測試所用URI如表2.

表2 測試URITable 2 URI testing

針對上述情況測試結(jié)果如下:

1)當(dāng)用戶進(jìn)行合法查詢請求時(shí)，系統(tǒng)通過接口返回?cái)?shù)據(jù)來驗(yàn)證用戶合法性并進(jìn)行處理，學(xué)生成績信息部分 Json 格式數(shù)據(jù)為:［{″XN″:″2013 －2014″，″XQ″:″1″，″KCMC″:″編譯原理″，″XF″:″3″，″CJ″:″緩考″，″JD″:″0″，″KCXZ″:″必修課″，″BKCJ″:null，″CXCJ″:null，″FXBJ″:″0″，″KCGS″:null}，…］返回結(jié)果如圖6.

圖6 基本信息查詢Fig.6 Results of basic information query

2)當(dāng)用戶進(jìn)行非法查詢請求時(shí)，系統(tǒng)驗(yàn)證用戶請求非法，不對用戶請求作出處理，返回錯(cuò)誤信息，返回結(jié)果如圖7.

圖7 非法請求結(jié)果Fig.7 Results of illegal request

3)當(dāng)用戶進(jìn)行錯(cuò)誤請求時(shí)，系統(tǒng)驗(yàn)證用戶請求模塊不存在，不對用戶請求作出處理，返回提示信息，返回結(jié)果如圖8.

圖8 錯(cuò)誤請求結(jié)果Fig.8 Results of error request

從測試結(jié)果來看，本系統(tǒng)針對不同的請求URL返回了不同的信息，所返回信息的格式與URL申明格式一致，系統(tǒng)接口完全符合REST風(fēng)格，開發(fā)者成功調(diào)用獲取相關(guān)數(shù)據(jù)及數(shù)據(jù)表現(xiàn)形式，由此可以看出，在框架化的系統(tǒng)支持下的REST風(fēng)格接口的調(diào)用簡單快速，整個(gè)系統(tǒng)也更加輕量.

5 結(jié)論

針對高校內(nèi)各教務(wù)系統(tǒng)平臺(tái)不統(tǒng)一，校園APP開發(fā)者獲取教務(wù)數(shù)據(jù)難度大這些問題，本文引入REST原則，以框架化的程序設(shè)計(jì)方法，構(gòu)建了一個(gè)基于REST的移動(dòng)教務(wù)高校數(shù)據(jù)開放平臺(tái).該平臺(tái)只需通過簡單的HTTP協(xié)議就可以完成數(shù)據(jù)調(diào)用和共享.雖然本系統(tǒng)的核心功能模塊不多，但是框架化的設(shè)計(jì)使得系統(tǒng)本身極易擴(kuò)展.測試說明系統(tǒng)運(yùn)行正常且非常輕量.但是本系統(tǒng)并沒有實(shí)現(xiàn)教務(wù)系統(tǒng)的大部分模塊，服務(wù)器負(fù)載均衡、數(shù)據(jù)庫優(yōu)化、安全機(jī)制等問題有待進(jìn)一步的研究.

References)

［1］ 黃小東.基于RESTful web服務(wù)與Oauth 2.0協(xié)議的高校教學(xué)數(shù)據(jù)開放平臺(tái)設(shè)計(jì)研究［J］.數(shù)字技術(shù)與應(yīng)用，2013(10):152－155.

［2］ 潘冰.基于Rails的RESTful Web Service研究與實(shí)現(xiàn)［J］.計(jì)算機(jī)應(yīng)用與軟件，2010，27(10):188－190.Pan Bing.Studying and implementing Rails-based Restful Web Service［J］.Computer Applications and Soft-ware，2010，27(10):188 －190.(in Chinese)

［3］ 阮一峰.理解RESTful架構(gòu)［EB/OL］.［2014－05－10］.http:∥www.ruanyifeng.com/blog/2011/09/restful.html.

［4］ 唐明偉.RESTful架構(gòu)下圖書管理系統(tǒng)的研究與實(shí)現(xiàn)［D］.南京:河海大學(xué)，2010.

［5］ Bryant P.REST －ful URI design［EB/OL］.［2014－05 －12］.http:∥blog.2partsmagic.com/restful－ uridesign.

［6］ 潘冰.基于Rails的RESTfulWebService研究與實(shí)現(xiàn)［D］.廣東:暨南大學(xué)，2010.

［7］ Aaron Saray.PHP設(shè)計(jì)模式［M］.北京:清華大學(xué)出版社，2010.

［8］ 潘冰.基于Rails的RESTfulWebService研究與實(shí)現(xiàn)［D］.廣東:暨南大學(xué)，2010.