《多终端Restful API框架设计研究及图书漂流系统应用》-工学论文，计算机论文-论文范文参考-科学狗论文网

标题

多终端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数据，为建设其他移动图书馆、微服务、轻应用等智慧图书馆应用提供了建设思路。

随便看

科学优质学术资源、百科知识分享平台，免费提供知识科普、生活经验分享、中外学术论文、各类范文、学术文献、教学资料、学术期刊、会议、报纸、杂志、工具书等各类资源检索、在线阅读和软件app下载服务。