多終端Restful API框架設計研究及圖書漂流系統應用

付敏峰 于林海

摘要：隨著圖書漂流活動思潮傳人國內，不同客戶端平臺上的圖書漂流系統層出不窮，缺少一套統一的適用于多終端的解決方案。在移動互聯網應用中，WEB API開發是前后端分離WEB應用開發的重要方面，結合MVC設計模式，構建一套基于REST風格的Restful接口應用框架，統一接口數據呈現格式，開發適用于各種客戶端使用的標準化接口。利用Flask框架定制實現圖書漂流系統的Restful API接口，提供網頁端和小程序端等多終端調用，提升用戶在不同終端的使用體驗。

關鍵詞：REST風格;API接口;RestfulAPI框架;flask框架;圖書漂流系統;多終端

中圖分類號：TP311 文獻標識碼：A

文章編號：1009-3044（2020）15-0004-04

1背景

“圖書漂流”起源于20世紀60年代的西方國家，近年來傳人到中國，這種不同于圖書館借閱和書店購買的新方式吸引了許多的年輕用戶群體，并作為一種新的閱讀方式傳人到校園。該活動以“分享、信任、傳播”為主旨，有助于培養學生的共享理念、誠信素質、奉獻精神等品質，是高校校園文化建設、圖書館閱讀推廣活動的有機組成部分。高校師生特別是畢業生擁有豐富的藏書和閑置圖書資源，共享經濟下實現圖書循環利用，不僅提高圖書利用率，提升圖書的使用價值，減少資源浪費，降低閱讀成本，也能彌補圖書館館藏圖書不足。

2圖書漂流現狀

圖書館的圖書共享服務主要指文獻借閱傳遞、館際互借等方式實現本館館藏圖書資源在不同高校圖書館之間的共享，本文是基于共享理念將個人閑置的圖書捐贈給需要的師生校友。目前，圖書漂流作為高校圖書傳遞共享的另一種方式，圖書館是圖書漂流組織者，為教師、學生捐贈的圖書放置在漂流站，用戶按照漂流規則取閱。圖書漂流活動能促進師生閑置圖書的共享，激發學生的讀書熱情，增進學生之間的友誼嘲。

因此，業內人士不斷探索圖書共享活動的組織和實現，結合移動互聯網平臺實現線上線下相結合的形式。如趙越嘲等設計并實現了高校圖書共享App，實現高校全民圖書隨時隨地共享。尹明章等借助微信的生態環境，利用微信小程序開發高校020圖書共享平臺，從控制成本、低投入方面改善用戶體驗和使用習慣。史欣璐基于社交網絡，采用Web網站和微信公眾平臺的模式開發了高校的圖書共享系統，實現用戶之間的共享、關注和評論。趙琰等開發了福建省文獻信息資源共享平臺“FULink圖書漂流”移動端App，實現紙質圖書在全省高校之間的漂流共享，諸如此類的應用及研究不勝枚舉。隨著移動互聯網應用的日益廣泛，移動端平臺層出不窮，微信公眾號、企業號、小程序、釘釘、易班、移動圖書館等平臺屢見不鮮，這些應用都出現在高校信息化發展歷程的各個方面，用戶為此需要安裝各類App應用，用戶體驗不佳。為提升高校信息化水平和適應用戶使用習慣，實現跨終端平臺的應用，因此，需要研究如何實現適用于各類客戶端平臺的跨平臺圖書漂移系統，考慮運營成本等因素，實現的圖書漂移系統系狹義的圖書捐贈功能，不再跟蹤圖書的漂移軌跡。3 Restful API

3.1 REST風格

REST（表現層狀態轉換，Representational State Transfer英文縮寫）是一種互聯網應用程序的系統架構風格，它利用URI（universal Resource Identifier，統一資源標識符）定位資源，用HTTP動詞描述操作。REST包含資源、表示、狀態3個主要內容。資源即網絡世界中一種體現為比特流的實物或抽象概念，每一個資源都有唯一的URI標識，通常使用URL表示。表示指資源所呈現出的某種形式，為構建松耦合、可擴展的Web應用提供標準嘲，對資源的操作是通過首先獲取該資源的現有表示，然后在內部完成從現有狀態到目標狀態的轉變，資源的操作即HTrP動詞POST、DELETE、PUT、GET對應的增刪改查四種。狀態既可以是服務器端資源狀態也可以是終端應用狀態，資源的狀態保存在服務端，應用狀態由應用自身維護。

REST將客戶端服務器模式的客戶端用戶界面和服務器端數據存儲所關心的不同問題分離開來，簡化服務器部分，改善其可擴展性和在不同平臺上的可移植性。所有交互都是無狀態的，每一個從客戶端到服務器的調用請求都要攜帶服務器處理請求時所需的全部信息，服務器端不保留和記憶任何狀態信息。統一標準交互界面，簡化架構、改善業務邏輯之間互動關系的可視性，業務邏輯與標準化界面的分離，使客戶端和服務器各自擴展，互不干擾。REST常用簡單、輕便、易用、可讀性強的JSON數據格式作為統一界面標準進行交互。

隨著移動互聯網和云服務應用的發展，REST以其設計簡單、讀取方便、數據包傳輸輕便等特點，被越來越多的開發者所使用，并逐漸用來取代復雜而笨重的SOAP Web Service模式。

3.2RestfulAPI內容

基于REST實現的Web架構約束的應用程序接口即為Restful AP，為不同客戶端開發者提供解決業務開發中接口可擴展性和終端異構性等問題。

互聯網中的資源是一個個實體，其狀態是隨著時間不斷發生變化的時間函數，在不同的時間節點其內容和狀態是變化的，在不同的應用場景或業務系統中，對同一資源所需的內容信息是不同的。因此，對于一個API接口而言，它可以是一個資源特定時間的某些基本信息，也可以是一個資源組合，或者是一些資源的狀態和另一些資源鏈接的組合。例如一個Web網頁資源除了包含有網頁的基本靜態信息外，還包括若干指向其他資源的鏈接。

API的調用就是一個資源組合的狀態返回，即從一個狀態的資源組合轉換到另一個資源組合并發生狀態改變的過程。資源狀態發送改變時，某些資源信息被獲取，還有一些資源信息會被修改，同時也會成為新資源組合中的一個鏈接或組成部分。

3.3RestfulAPI結構

一個API能將資源組合中的若干資源從一個狀態轉換到另一個狀態，其內部結構如下圖1所示。API結構內部分別由訪問控制、API定義和業務邏輯三部分組成，訪問控制約定API的開放程度、權限要求以及性能質量的監控等，API定義部分規定API的功能作用、訪問方式、URL設計、參數約束、返回結果等，而業務邏輯則是完成整個API功能，實現業務邏輯的主體，通過與數據庫、業務系統、互聯網或本地的API等資源的交互，進行適當的邏輯處理，返回API功能的資源組合。

在互聯網環境下，公開的API接口僅需要提供給客戶端有關資源的詳細信息及其他有關聯的信息，而不考慮客戶端獲取資源的用途和業務功能。但作為企業或校園內部的API設計，不僅要有獲取資源的接口，更重要的是考慮資源如何利用、接口粒度大小如何設計才能方便客戶端使用等內部業務，以便于讓業務系統輕松完成業務邏輯，而不需要過多處理接口數據。

根據內部業務需要和Restful API設計原則，將內部環境的API體系結構重新構建為多層嵌套的API體系結構。由內而外之下而上依次是：面向獨立的資源數據、粒度最小、幾乎不含業務的資源API，需要調用資源API處理相關邏輯業務或功能需求的邏輯功能API，以及直接面向客戶端用戶的，需要對各終端提供個性化資源的前端API。結合MVC設計思想，可以將資源API、邏輯API和客戶端API三層演化對應MVC的層級，如圖2所示。

嵌套關系的三層API結構是根據接口的功能和形式進行劃分，并非邏輯結構上的分層。各層之間相互串聯，下層為上層提供服務、輸出資源，上層從下層取得資源完成自己的使命功能，對外每層的接口又都作為獨立的個體存在，都面向客戶端開放，提供接口服務。

4基于Flask實現Restfui API框架

4.1 Python Web框架Flask

Flask是目前十分流行的Python語言Web微框架，在GitHub上Flask的Stars數已上升至49.3K，已超過同類的Py-thon Web框架Django（47.6K），躍居第一。它是一個輕量級的可定制框架，較其他同類型框架更為靈活、輕便、安全且容易上手，可以結合MVC模式進行開發和按需定制。

4.2基于Flask設計的Restful API結構

在前后端分離的背景下，現在常用的Web服務架構體系一般根據結構功能分為數據存儲層、業務處理層和前端頁面展示層。基于Flask框架實現業務處理層的所有邏輯功能，從各類應用或存儲中獲取資源，建立一個個滿足一定功能或設計資源的API接口，前端調用接口實現其個性化的業務。Flask框架實現的三層Restful API Web結構體系如下圖3所示。

在RestfulAPI結構體系內部，通過基于JWT的認證權限機制實現接口鑒權管理，包括CMS數據管理均統一通過API進行交互。控制器層是整個API工作的調度中心，它將整個的路由、鑒權、數據的接收和驗證、異常處理、業務處理、返回結果等所有工作串聯起來。通過Flask框架的視圖函數實現控制器層的工作，裝飾器完成業務請求的路由和鑒權工作，保護控制器不被惡意調用和處理額外事務，使其專注于調度業務處理。控制器調度的第一項工作就是驗證用戶請求參數，交由統一數據驗證層實現參數的合法性、有效性驗證。業務模型層完成業務相關的數據和邏輯處理，是API業務功能實現的核心。視圖模型層在整個的框架中不是必不可少的，它根據客戶端的要求處理業務層完成的結果數據，按需將核心數據提供給客戶端。JSON序列化即數據結構轉換，將開發語言中數據呈現的結構對象轉換為ison字符串形式返回給客戶端。所有的處理過程中出現的異常、錯誤等統一由AOP統一異常處理層接收并返回。

4.3 Api的Url地址設計

使用Url標識網絡中的唯一資源，一個Url表示一個api接口。設計一個Restful Api接口中需要包含REST風格中資源標識、接口操作、版本號、以及結果識別等。不同于普通的Web頁面，接口使用“api”作為Web上下文，使用二級域名或Api標識，在API的Url中增加版本標識（如v1），資源標識到具體的Api中;形如http：//域名/api/v1/user的接口格式。利用HTTP動詞完成API調用的請求方法操作，REST使用HTYP的狀態碼識別API調用情況。

4.4 HTTP狀態碼及錯誤碼

HTTP狀態碼常用的如2**表示操作成功，3**表示重定向，4**表示沒有權限、無資源、不被允許等，500一般表示服務器端出現內部錯誤，客戶端需要根據狀態碼判斷其請求結果。

對于API接口調用結果除HTTP狀態碼外，還需要使用JSON統一返回數據格式，結果類型大致可以分成業務數據信息、操作成功的提示信息、錯誤異常信息三類。業務數據信息反饋接口功能提供的字段信息，有單個記錄或集合數據。錯誤異常信息定義的格式需要指明出現錯誤的錯誤碼、錯誤提示以及調用地址信息。一套完整的接口系統需要有專門的錯誤碼列表，標識每種錯誤碼對應出錯的原因和相關解釋說明，錯誤碼一般是多位的數字，此處設為4位。如無權限查詢記錄的異常信息：{“errorCode”：1001，“message”：”Forbidden，no permis-sion”，”requestUrl”："GET/vl/used5”}。與錯誤異常信息返回格式一致，對操作成功的提示信息也需要統一定義，如添加一條記錄成功的返回信息：{“errorCode”：O，“message”："success”，”re_questUrl”：“POST/v1/article/add”}。

5圖書漂流系統

圖書漂流系統主要利用Flask框架定制開發實現異構終端的RestfulAPI接口，并由微信小程序、Web端調用實現的圖書漂流系統。由用戶管理模塊、圖書模塊、捐贈模塊、索取模塊和圖書漂移模塊組成，實現將師生手中閑置的圖書捐贈或共享給需要的用戶，考慮流通等成本因素，平臺使用用戶實名認證、圖書線上漂移、線下傳遞的模式。

用戶注冊要求使用學校統一身份認證實名認證并完善用戶聯系方式信息，支持不同客戶端的用戶注冊。圖書模塊利用網絡爬蟲將用戶搜索到書籍的封面、介紹等基本信息保存到本地數據庫，禮物清單和索取清單分別存儲有漂移意圖的圖書ISBN信息和用戶信息。捐贈模塊用戶將自己閑置的圖書作為一個禮物進行上傳，構成捐贈的禮物清單，相反索取模塊是展示用戶想要的清單。圖4所示為各模塊完成的功能及用戶贈送書籍或索取的路徑。

讀者通過圖書模塊搜索圖書，圖書詳情展示圖書外，也列當前贈送此書的用戶列表，在詳情頁讀者根據需要可將書籍添加到自己的禮物清單或索取清單，也可以直接向贈送此書的讀者發送請求。索取清單列出讀者想要的所有書籍，每本書后附帶該書已在禮物清單的所有讀者，并可以向某讀者發一條請求其贈送的通知。禮物清單中的禮物后面列出所有索取該書籍的讀者，并可以選擇讀者向其發起贈送的圖漂，圖漂建立成功后，通知用戶線下完成。

在圖書漂移系統中，實現的若干RestfulAPI如表1列出所示。

6結束語

標準REST要求將一切資源化，提供標準化的資源屬性返回給用戶，不考慮返回結果的合理性與實用性。但在實際應用場景中，除了操作資源外，更多的是利用資源實現內部業務功能，REST限制的資源增刪改查操作很難滿足復雜業務的邏輯，為了實現一個業務邏輯，也許會多次調用不同的接口，不僅增加服務器壓力和前端開發難度，而且資源的粒度也不好掌握。因此為了更好地實現企業、學校等內部環境的REST風格API設計，吸收其優秀的設計風格和良好的格式約束，但也不拘泥于嚴格執行其不便于實現功能業務邏輯的規范要求，設計的基于FLASK框架的RestfulAPI結構體系，實現了多終端的圖書漂流業務的接口，適用于各種平臺調用數據使用，為圖書漂移輕松擴展其他平臺應用提供了API數據，為建設其他移動圖書館、微服務、輕應用等智慧圖書館應用提供了建設思路。