基于REST的银行信贷系统API体系研究

随着企业IT建设的推进，企业内部信息系统越来越多样化、异构化，系统间信息交换和实时交互愈发频繁，对信息资源整合提出了更高的要求。为解决系统间资源整合和实时交互问题，曾经出现过多种架构方案：如CORBA、RMI、EJB等分布式对象，XML-RPC、Web Service、JMS消息等远程过程调用。分布式对象没有统一接口的概念，异构系统间分布式对象调用难度很大；而远程过程调用方式则容易造成客户端与服务器端紧耦合，性能不好。

　　企业信息系统应提供统一的接口，构建简洁高效的实时API体系。API体系应满足这些要求：统一，采用标准的接口规范；松耦合，与客户端及语言无关；简单，有成熟的应用工具，易于开发测试。

一、REST架构风格

　　1．REST概念。

        REST(RepresentationaI StateTransfer，表述性状态转移)是HTTP/1.1协议的设计指导原则，是现代WEB体系中最为成功的分布式应用架构风格。REST以资源为中心，以超文本驱动，通过统一的接口转移和操作资源的表述，来间接实现操作资源的目的。

　　资源是服务器内容的抽象方式，一个资源可以由一个或多个URI标识，对资源感兴趣的客户端应用，通过资源的U RI与其进行交互；资源的表述是一段对于资源在某个特定时刻的状态的描述，可以在客户端一服务器端之间转移，客户端通常可以请求不同格式的资源表述；超文本驱动是指将应用看作是一个由很多状态组成的有限状态机，资源之间通过超链接相互关联，超链接既代表资源之间的关系，也代表可执行的状态迁移；统一的接口是对资源的操作规范，每个资源只能执行一组有限的操作，常见的REST架构实现中一般采用HTTP/1.1协议作为操作资源的统一接口规范，主要包括HTTP方法、HTTP头信息、HTTP响应状态代码、HTTP内容协商机制、缓存机制、身份认证机制等。

　　2．REST的优点。主要包括以下几点。

　　简单性。由于REST采用统一接口，资源的URI一旦确定，即使资源还不存在，客户端也已经明确操作资源的方式。REST还可以充分利用大量现成的HTTP服务器端和客户端开发库、HTTP缓存、HTTP代理服务器等。

　　可伸缩性。由于REST是无状态的，服务器端无需保存会话上下文，因此可以方便地在服务器端横向扩展；同时可以充分利用通信链各个环节的HTTP缓存组件，从而带来更好的可伸缩性。

　　松耦合。REST采用统一接口和超文本，使得服务器端和客户端可以相对独立地演进。

二、基于REST的银行信贷系统AP I体系

　　银行信贷系统(或信贷类系统群)作为银行主营业务的IT管理系统，其内部包含多个数据域，外部又涉及多个与之交互的信息系统，必然存在大量的对内对外信息交互需求。由于REST更简单、拥有更好的伸缩性，基于REST的实时API体系将比传统的信息交换更具优势。

　　1．银行信贷数据域与资源抽象。银行信贷业务数据通常包括当事人、产品、协议、事件、资产、风险、财务等主题域。这些主题域的业务数据往往分布在多个系统中，例如当事人主题下的客户数据一般在客户关系管理系统中；协议主题下的授信数据、合同数据、贷款数据可能分布在信贷系统、核心账务系统中；风险主题下的评级信息、资产质量信息可能分布在评级系统、风险管理系统中。

　　跨系统的数据整合和系统交互是传统架构需要解决的最大难题。REST架构以资源为中心，并不关心资源所属的具体系统。以“客户一授信一合同一贷款”为主线，建立与系统无关的资源抽象(见图1)。

图1 信贷数据域资源抽象

　　2．接口设计。正如上文的介绍，所有资源都具备统一的操作接口，一旦完成对资源的抽象，基本就完成了API接口设计，所有操作接口也就确定了。例如，对合同资源，使用不同的HTTP动词对URI发起请求，即可实现对资源的操作。GET /contracts/：id.json获取ID为：id的合同信息，请求返回json格式

　　GET /contracts.xml获取所有的合同，请求返回xml格式

　　POST/contracts创建合同

　　PUT/contracts/.id 更新ID为：id的合同

　　DELETE/contracts/：id 删除ID为：id的合同

　　对其他资源的操作接口与此完全相同，区别在于资源的URI不同。在少数情况下，可以根据需要适当扩展接口。除此之外只需要根据业务内容填充和完善资源的表述及其状态之间的转移，设计资源之间的连通关系即可。

　　3．实现方式。建设API体系主要包括以下三种方式。

　　分布式。推荐采用分布式建设方案，即由各系统按照REST接口标准实现各自的API，按照规范发布接口。优点是操作逻辑由业务系统控制，缺点是需要在存量系统中引入REST风格的接口方案。

　　集中式。即全新建设一个API平台，集中发布API接口。实现时需要取得各应用系统的数据访问权限，并且需要熟悉其他业务系统的业务逻辑。适用于组织内存在强有力的数据管理部门，能够协调数据资源，特别适用于只提供查询API的场景。其优点是方便API体系的管理，系统间的接口可在API平台进行整合；缺点是API需要跟随业务系统变化而变化，容易产生与业务系统不同步的情况。

　　集中式与分布式结合。集中在API平台实现那些需要跨系统整合或组装的接口，各系统各自实现与自身业务逻辑密切相关的接口。在大多数情况下，集中式与分布式相结合是一种可行的折衷方案。

　　4．版本并存。在对已发布的服务进行变更时，要尽量做到兼容，包括URI、链接和资源表述的兼容，在接口扩展时不能破坏现有的客户端应用。必要时应通过增加API的命名空间，同时提供多个API版本。例如，对合同的API增加版本号：

　　GET /v1/contracts.xml 获取所有的合同，V1版APIGET /v2/contracts.xml 获取所有的合同，V2版API

　　5．安全机制。认证方面，在REST中，保护API安全与其他web应用并无差异，接入时首先对客户端做身份认证，可采用基于密钥签名的认证机制、标准的HTTP身份认证机制、OAuth协议认证等方式；加密方面，可部署SSL基础设施，传输敏感数据时全部基于HTTPS，同时加入随机数进行混淆，以防范数据被篡改；授权方面，通常在API服务端对访问用户实现基于角色的授权机制。

（文章来源：《金融电子化》杂志）

扫码即可手机
阅读转发此文