基于HttpClient接口开发实例（一）

前言

本系列将是本人的一些开发经验总结。由于身处金融IT因而因业务需求需要和银行接口打交道，恰巧最近公司有个项目和这有很大的关系，下面我们将着重从基于HttpClient接口开发的技术点+基本业务点说起。这算是公司内部比较机密的东西因而不能做过多的说明。本系列以后牵涉到的概念的业务逻辑都将是最基本的，核心的实现的逻辑不陈述。

---

概述

本系列陈述的将是基于HttpClient接口开发的实例，在实际的需求中和案例中Server间接口的数据传输方式有很多种比如Http(HttpClient)/WebService/Socket等等。

• 使用场景
  
  • Http：接口间的数据传输使用Http比较多一点。即指定Protocol 为Http
  • WebService：Server与Server之间的通信使用WebService多一点比如WSDL。
  • Socket：多数应用场景为Server 与 Client 之间的通信，在Server和Client之间指定一对端口，然后接一个Socket再然后指定一下Protocol，然后双方就可以通信了。

---

HttpClient && JSON

首先基于HttpClient之间的接口开发需要在接口之间做一些约定，简而言之就是一些通信规则，若是不规范的通信将不予以处理或者直接通信失败。接口间常用的规则和约定有通信方式、规则和约定、安全方式、交易模式等等。下面我们将以一对基于HttpClient 传输JSON报文的实例来陈述。

• 通讯方式

  • 后台
    双方约定接口的通信方式比如采取的Https Post方式来传输JSON数据报文。
  • 页面
    在一些实际的业务需求中双方可能会用到彼此的页面或以H5的页面展示或者其他的页面形式展示，因而双方约定页面间的通信方式比如Https。
  • 文件
    在一些场景下Server间的可能会使用文件传输协议来满足一些实际的业务需求，因而双方也许约定系统间的文件传输协议比如Https。

• 规则及约定

  • 报文规则
    报文采用JSON格式来传输接口数据，对于一些必须出现的Mandatory字段必须上送，一些可选出现的Optional字段可上送可不上送。

  • 字段约定
    在上送的JSON point中，需要对字段类型做约束，比如：char、date、time、decimal…

  • 编码方式
    需要指定报文的编码方式比如UTF-8

  • 字段长度计算说明
    字段长度的计算说明：所有长度均按字节计算，中文算三个字节，英文、数字算一个字节。

  • 特殊字段说明

  • 报文结构

    • 请求报文
      一个完整的请求报文应包含头部和报文主干部分，我们称之为Header和Body。

    • 应答报文
      对于一个应答报文而言，必须包含头部，即Header部分，Body部分可有无。

  • 加签加密,解密解签说明
    这是接口间通信保证数据正确完整传输的最最关键环节。很多基于HttpClient的接口通信都必须要做到一点，处理请求报文使用秘钥加密加签，处理应答报文使用公钥解密验签。此处便牵涉到一个非对称加密解密的概念，对于不太了解非对称加密的同学请参考官方文档。在实际的业务需求实现中我也将会详细说明一个非对称秘钥在接口通信间的使用的例子。这里不赘述。

• 安全方式
  在实际的JSON请求或者应答报文中有一些敏感信息是需要加密传输的，此外之前我提到的加签加密，解密解签的规则也需要双方约定好。
  比如现在有一个完整的请求报文，我们需要对它的Body做TreeMap排序(升序或者降序)，然后通过加时间戳按一定规则生成一个明文字符串A，然后将该明文字符串使用我们的自己的秘钥加签并生成一个明文加签之后的字符串B或者数组B，然后再对B使用一定的加密规则(一定是可逆的比如Base64)生成一个密文C，再将这个密文C放到请求报文的Header中(通常而言我们称之为签名)。
  对方在收到我们的请求报文之后首先会校验报文的完整性，然后获取Header中的签名C1和时间戳T1，并按照双方约定的机密算法解密得到一个字符串或者数组B1，然后再使用我们提供的公钥验签得到一个原生的明文字符串A1，然后对整个请求报文的Body做逆运算，本例子：将Body做TreepMap排序，然后结合T1按一定的规则生成一个明文的字符串A2，最后将A1和A2作比较，若一致则表示验签成功，数据正确完整地传输，否则表示验签失败，验签失败有一些原因比如生成的签名没有严格按照双方约定执行，或者在数据in-the-fly的过程中被篡改或者丢失。只有在验签的成功情况下在处理该次请求，否则不处理。

• 交易模式
  在HttpClient的请求中有两个通信模式一个叫同步请求，另一个叫异步请求。对于什么是HttpClient的同步和异步请求，网上有很多例子的说明，这里不赘述。下面我们所说的系统间的同步交易和异步交易将会和如上的同步异步存在着本质的区别。下面我将讨论一下三种基本的交易模式。

• 后台同步交易
  
  说明：首先A平台使用HttpClient通信请求将信息发送至B平台，B平台处理并返回响应报文；若A等待响应报文超时可再次发起同步请求。

• 后台异步交易
  
  说明：首先A平台发起同步请求(需要C平台介入处理的请求)，B平台同步响应该次请求结果，同时B会将该次请求交至第三方处理C平台处理，第三方把处理结果返回给B，然后B将通过调用和A约定好的异步回调接口把第一步请求的接口返回给A平台，A平台收到请求之后将第五步的处理结果返回给B。
  在整个请求的处理过程中从第二步完成之后到第四步完成可能会需要一定的时间段，因而A/B平台不能实时开着线程I/O去等待响应，于是用过异步接口回调的方式把异步处理结果返回。其中1-2步和5-6使用HttpClient同步请求，3-4用一些基于protocol的方法进行数据交互，因而整个请求处理过程而言可以看做是一个异步交易。
• 对账类交易
  
  说明：对于对账类交易的实现是基于HttpClient 同步请求和系统间同步请求完成的。A和B间完成文件传输有两种情况，第一种是B主动推送文件通知消息报文请求，A平台同步响应，第二种是A平台主动发起文件状态查询，B平台同步响应。双方经过以上”握手”响应之后B向A发情Https 文件传输请求。

---

小结

• 对于接口间数据通信的开发，双方需要制定一些规则以确保双方间的通信过程中数据的完整和可用。这些规则例如：HttpClient JSON/报文加签/敏感信息加密/….
• 对于实际的业务实现，可根据双方实际情况而定，唯一可以确定的是任何一个业务逻辑的实现都是基于以上规则进行的。
• 在实际的开发过程中，建议先将整个项目的连贯起来，然后再去做逐个的实现。