宛寧
(長春工業大學,吉林 長春 130012)
高校信息門戶系統API設計
宛寧
(長春工業大學,吉林 長春 130012)
為提升高校信息門戶系統底層數據交互的安全性、高效性、復用性,提出在信息門戶系統中通過API接口來取代數據庫接口獲取數據的傳統方式。并以長春工業大學信息門戶系統數據層設計與實現為實例,制定信息門戶系統數據接口設計方案。
信息門戶;API;數據格式標準
傳統信息門戶與各業務系統接口或數據庫緊密連接,導致信息門戶系統的訪問對各業務系統造成了巨大負擔。移動終端的出現對信息門戶有了更多的需求,數據展現的二次開發在所難免。為此,基于API的數據模型能夠更好地為新一代的信息門戶系統服務[1]。
目前,普遍采用基于HTTP協議的數據接口,數據格式常采用XML或JSON。隨著API接口數量的增減,如沒有一個好的標準設計和數據規劃,不論使用哪種協議哪種格式,都將適得其反。為此,我們要將數據層面各個業務系統數據交換到中間數據庫,隔絕應用層與業務系統的直接關聯。應用層直接訪問API,API直接訪問中間數據庫。
我們知道,信息門戶不是一套獨立的系統,本身不產任何數據,也不對任何數據進行轉化操作。它直接將最新的信息、重要的數據以Portal的形式展現出來,將各應用系統的部分功能集成并提供服務,根據不同角色展示不同的信息[2]。信息門戶可以比喻成電腦上的瀏覽器,如果沒有互聯網,沒有各網站應用,瀏覽器就是一個空殼。用戶訪問信息門戶系統并不關注信息門戶系統本身,關注的是里面的數據、信息、業務系統服務。在具備完整數據支持和技術支持的條件下,任何開源信息門戶系統還是商用信息門戶系統都能夠快速部署并投入使用[3]。因此,一個高校信息門戶系統好不好,體現在里面的數據和功能服務上。信息門戶系統的好壞直接體現高校信息化建設的程度。
在高校中構建API數據接口是最近幾年才流行起來的。過往我們的需求較為單一,沒有那么多的終端要求。但隨著數字化校園建設的提出,業務系統與業務系統之間、信息門戶與業務系統之間需要大量的數據關聯。一開始,各應用系統都開發了基于SOA的各自獨立的數據接口。但這些接口都是私有接口,系統與系統間沒有統一的標準和規范。隨著中間共享數據庫的建立,提取數據不再是從各個業務系統來獲取,導致需要定義新的API數據接口。
隨著移動終端的飛速發展,人們的互聯網生活習慣也發生了改變。上網不再是只能通過計算機進行,還可以通過移動終端隨時隨地進行訪問。每個人習慣不同,有喜歡直接通過手機瀏覽器訪問的,有喜歡通過APP方式訪問的,還有喜歡用微信平臺訪問的。為此,我們需要開發多終端的信息門戶應用程序來滿足用戶的需求。
為了滿足上述需求,我們針對不同的終端需求開發新的信息門戶,開發過程中必然涉及到用PC端的信息門戶一樣的問題,即數據的獲取與交互的方式方法。以往的信息門戶僅考慮到PC端用戶的需求,所以在開發設計時數據的獲取與交互方式方法不一,有直接抓取過濾的,有直接連接數據庫的,還有直接連接業務系統接口的。這導致我們在開發其他終端信息門戶系統時需要重寫程序,一旦源數據系統出現變動,所有的程序都要重新編寫。為此,我們需要一個統一的數據接口,所有終端系統采用統一的標準進行數據的獲取與交互。未來如果新的應用系統上線,我們構建的API數據接口能夠快速提供數據服務支持。
早期的信息門戶系統與各業務系統是直接連接的。例如在信息門戶系統中訪問成績數據,那么信息門戶服務器會直接訪問教務系統的數據庫。一旦教務系統出現故障,將直接導致信息門戶訪問受到限制。隨著數據交換和中間數據庫的提出,我們將業務系統中的數據通過數據交換工具同步到中間數據庫中,中間數據庫與信息門戶相連,避免了上述問題,同時減輕了業務系統負擔。但從安全角度講,一旦信息門戶遭到入侵,學校重要數據有被竊取的危險。
為此我們提出基于API的無數據庫連接的信息門戶系統。信息門戶系統與數據層中間通過API數據接口進行連接,API服務器與業務系統或中間數據庫進行直連,通過自定義的接口方法進行交互。因此,一個標準API結構為:業務系統數據(業務層)-〉數據交換(數據交換層)-〉中間數據庫(中間數據層)-〉API數據接口(接口層)-〉信息門戶系統(訪問層)。
由于信息門戶系統需要從各應用系統獲取數據,數據形式多種多樣,因此我們需要開發大量的API數據接口。為了使API接口更加規范有序,需要制定接口名稱標準,數據格式標準。
接口名稱標準。每組數據都來自各自的應用系統,因此建議先將校內各應用系統進行名稱編碼。例如:通知通告系統10001、本專科教務系統為20001,科研處網站系統300001。這里前兩位代表系統類型,后三位表示系統序號。例如10表示全校范圍內的信息發布系統類型,20表示各業務部門應用系統,30表示各部門網站系統。下一步是制定各個應用系統的API數據接口編號,一般由3到4位數字組成即可。下面的表格是本課題實施過程中為教務系統設計的API編碼標準部分片段,獲取數據時只需要通過URI格式為“http∶//IP/system_id/20001/api_id/a01/userid/20140013”就 可以直接獲取到學號為20140013的學生當前學期的課程表了。然后就是輸出的數據格式標準,在本課題實施中采用的是RESTful協議標準,返回JSON格式的數據,通過程序可以將獲取到的JSON數據直接格式化成數組或對象。
API數據接口主要由三層結構組成,分別是數據連接層、數據處理層、數據表示層。
數據連接層主要負責API與中間數據庫、內存數據庫、業務系統數據庫進行連接獲取原始數據。在設計時一般將所有數據連接類型歸為一個類,連接參數以配置文件方式進行配置。參數中比較重要的是連接類型,連接類型決定使用數據連接類型類中的哪種方法。目前主要的連接有Mysql、Oracle、SqlServer、Webservice等等,要注意各類數據庫各版本的支持。
數據處理層主要負責將獲取到的數據進行加工整理。例如從中間數據庫獲取到某學生的基本信息,其中家庭信息是采用逗號和分號進行分隔,數據處理層將數據進行重新整理為數組格式。在設計時一般將每個業務系統作為一個類,類名最好包含系統的編碼。例如教務系統編碼為20001,那么就可以創建一個名為api_20001.class的類文件。各個類是相對獨立的,但經常遇到一個功能請求需要多個業務系統數據組合的情況。例如需要得到某教師工資和人事基本信息表格,一種方法是生成兩個請求從兩個類中各取數據,具體結果直接在信息門戶系統中完成;另一種是針對耦合請求創建接口(程序設計中面向對象的接口),該接口連接工資系統API類和人事系統API類,進而完成數據請求與處理。前一種方法會增加信息門戶系統的UI開發量,增加了新增終端的開發工作量,第二種方法可以在表示層進行統一設計,信息門戶終端直接獲取數據即可。
數據表示層將信息門戶的HTTP接口請求進行分析,根據分析到數據處理層獲取需要的數據,將數據進行格式化返回結果。例如數據表示層將一個請求分解為system_id=20001、api_id=a01、user_id=20171234,數據層立即引用 api_20001.class并創建一個對象,使用方法a01獲取學號為20171234的學生的當前學期課表。獲取到的課表格式化為JSON格式返回給信息門戶。數據表示層除了格式化數據為XML、JSON、text格式外,還可以提供最為直接帶有UI的Web格式。在設計中,我們提供了WebAPI接口方法,只要采用該方法可以直接返回HTML5頁面展現信息,信息門戶僅提供URL可驗證的安全跳轉即可。
課題組經過接近半年的時間,對學校信息系統數據進行了重新整理,通過開源數據交換工具將數據集中到中間庫,通過輕量級的API為新版信息門戶、手機APP、微信企業號、服務號、訂閱號提供了各類應用數據接口支持,效果明顯。但對于大數據例如個人消費流水、日志信息等實現API到中間庫獲取的方式效率極低,有待日后優化。
[1]王平.統一信息門戶建設方案探討[J].科技視界,2015(35):172+208.
[2]吳曉,李丹寧.基于SOA架構的企業信息門戶實現[J].貴州科學,2015(06):14-19. [3]鄧子龍.數字校園中基于Web Services數據交換平臺的設計與實現[D].西安:西安科技大學,2014.
[4]楊帆.基于SOA數據交換方法與技術的研究[D].西安:西安電子科技大學,2014.
API Design of University Information Portal System
Wan Ning
(Changchun University of Technology,Changchun 130012,Jilin)
In order to improve the security,efficiency and reusability of the bottom data interaction in university information portal system,the way to obtain data through the API interface in the information portal system is put forward which replaces the traditional way through database interface.Taking the design and implementation of the data portal of the information portal system of Changchun University of Technology as an example,the data interface design scheme is made.
information portal;API;data format standard
TP393.09
A
1008-6609(2017)10-0063-02
宛寧(1981-),男,吉林長春人,碩士,工程師,研究方向為數字化校園建設、數據中心設計與實施、應用程序開發。