浅谈系统数据交互-Webapi接口

• 一、发展历程

  1.1 简介

在日常软件开发过程中，避免不了系统内、系统间进行数据交互。尤其是对于产品前后端分离的研发过程中，Webapi开发是尤为重要，它是前后端数据交互的核心；

      1.2 接口方式

方式	说明
物理文件交互	把相关数据按照要求生成一个数据库文件格式，用以双方交互以及结果反写；2012年曾经在广东某地早期医保接口交互采用此方式；
Dll(动态库)交互	动态链接库文件，是一种不可执行的二进制程序文件，它允许程序共享执行特殊任务所必需的代码和其他资源； Ps:2014年之前相关业务嵌入接口，DLL动态库模式较多，主要涉及一些设备驱动、医保读卡
Webservice(Soap)	是一个平台独立的，低耦合的，自包含的、基于可编程的web的应用程序，使用开放的XML（标准通用标记语言下的一个子集）标准来描述、发布、发现、协调和配置这些应用程序;此类接口对方法、参数详细描述，第三方调用需要导入说明文件进行相关调用，这就导致方法或者入参变更需要重新导入，对调用方不太友好
数据库交互	提供数据库特定访问权限，提供视图、存储过程方式调用来进行数据交互
Webscoket	WebSocket是一种在单个TCP连接上进行全双工通信的协议；大量应用于web网页驱动硬件设备（读卡、身份识别、高拍仪）等
Webapi(RESTful API)	是一种基于HTTP协议的应用程序接口，它允许不同的软件应用程序通过网络进行通信和数据交换

• 二、 Webapi发展

随着互联网技术的发展，WebApi作为一种轻量级的服务选择，被广泛应用于各种互联网应用中。WebApi的优点在于其简单、易用、性能高等特点。

         2.1 产品研发方式

                2.1.1 集成式开发

传统C/S端研发，基本都是界面与数据交互融合或者分离模块(DLL)方式，数据访问直连数据库，连接池以程序运行为连接，以程序断开为释放节点，数据即查即用，响应速度快；

               优点

主要包括敏捷开发速度快，‌可以节省成本，‌前端和后端一个人独立搞定，‌这种开发往往是单一的一个项目。‌相对的，‌使用接口式开发，‌做前后端分离，‌往往是多个项目组成的一个大项目，‌项目大，‌周期长，‌需要团队协作

                缺点

在于前后端工程师在开发过程中可能存在较高的耦合度，‌即前后端工程师在开发过程中相互依赖，‌一旦某一方的工作出现问题，‌可能会影响到整个项目的进度和质量

         2.1.2 前后端分离

 优点

1. 提升开发效率：前后端分离允许前端和后端团队并行开发，减少了依赖和等待时间，从而加快了整体开发进度。
2. 改善用户体验：通过Ajax等技术，可以实现页面的局部刷新，提供更流畅的用户界面交互体验。
3. 便于团队协作：前后端分离使得团队可以更专注于各自的任务，如前端专注于UI和交互，后端专注于数据处理和业务逻辑，这有助于提高团队的工作效率和专业性。
4. 提高代码复用性：分离前后端的逻辑使得代码更易于维护和扩展，提高了代码的复用性和可维护性。

 缺点

首次渲染时间较长：由于需要加载更多的资源，首次页面渲染时间可能会比传统方式长。

可能影响SEO：因为前后端分离可能导致某些页面元素或数据在搜索引擎爬虫抓取时不可见或不可用，这可能影响网站的搜索引擎优化。

增加技术复杂性：前后端分离需要更复杂的技术栈和更多的配置管理，这对于小型项目或非专业团队来说可能是一个挑战。

2.2 Webapi

 2.2.1 业务与数据解耦

    Web API将前端展示逻辑与后端数据处理逻辑分离，使得前后端可以独立开发和部署，提高了开发并行度和可维护性。

2.2.2 跨平台数据交互

     Web API采用标准的HTTP协议，使得不同平台（如iOS、Android、Web等）和设备（如手机、平板、桌面应用等）可以轻松地调用和交互数据。

2.2.3 提供统一的数据访问接口

      Web API为内部和外部应用提供统一的数据访问接口，便于数据的统一管理和安全控制。

2.2.4 扩展性和灵活性

Web API易于扩展和灵活配置，可以根据业务需求快速添加新的数据资源和方法。

• 三、Webapi安全性策略设计

  3.1 接口设计原则

  3.1.1 统一报文、响应

针对报文请求、响应做统一设定；授权ID，授权秘钥key

例如：

请求：

{

    "appid": "",

    "appsecret": "",

    "requestdate": "2024-07-10 09:38:05.788",

    "messageid": "",

    "timestamp": "1720604285",

    "enctype": "",

    "version": "",

    "optercode": "",

    "optername": "",

    "signno": "78dc7716a12f2f917746b3c98bff61e2d297614809030e91e50ae2ffc7c5b1f4",

    "data": "0bce5eac5d4951ed43d80ef7a5db0f416f10a6a0bd3bdf25162b34fcdfa10f878666979375a162f33bbe42394ca05fb9e1257ab7cc1d13e11ce601c3df2e2c82"

}

响应：

{

    "appid": "d54c0974275e494895689c36f6269948",

    "receivedate": null,

    "requestdate": "2024-07-10 09:38:05.788",

    "messageid": "",

    "responmsgid": null,

    "timestamp": "1720575480",

    "responmessage": "成功",

    "responcode": 0,

    "respondate": "2024-07-10 09:37:59.858",

    "signno": "",

    "respondata": [

        {

          

        }

    ]

}

3.1.2 负载均衡

采用Nginx进行负载均衡,作为高效的HTTP 负载均衡器，将流量分布到多个应用服务器，提高webapi的性能、可扩展性和可靠性。

3.2 接口安全性策略

  3.2.1 秘钥机制

    采用授权、秘钥机制访问策略来防止接口暴露、隐私数据被泄露；

  3.2.2 加密机制

       采用针对appid、秘钥、入参、时间戳、随机数方式对报文体的进行加密，避免明文请求，防止数据泄露风险；

  3.2.3 验签机制

        针对加密数据，按照数据序列化要求对签名对比，确认相关请求由授权方发起调用，避免恶意模仿请求，导致业务系统数据、业务泄露风险；

  3.2.4 时间戳机制

        针对请求由限时要求，可以配置多长时间请求会被过滤，不允许发起请求；特殊业务例如充值、核心业务的报文被破解或者再次请求会导致系统稳定性降低、风险系数大大增加，同时避免恶意、多次频繁请求；

   3.2.5 请求唯一机制

        报文唯一消息ID，用于跟踪报文入出参同时，同一消息请求不允许被再次发起，可以接口Redis缓存机制，有效避免批量恶意者多次发起请求测试，导致接口性能降低、甚至崩溃；

• 四 Webapi设计实践

     4.1 授权配置

• 

        4.2 加密配置