对HttpRest接口服务接入思考02(1.23)

基于上篇的思路，对于当前的SOA管控和治理平台，需要考虑如何增量平滑的支撑Http Rest接口服务。

1. 对于新的Http Rest接口的注册和接入

对于当前已有的基于SOAP WS的服务规范定义文档，最好的方式就是做到SOAP和REST接口都能给通用，虽然这样不符合Rest面向资源的要求，也丧失了Rest接口本身的一些灵活性，但是可提升对服务规范的标准化管理。在这种模式下，对于服务规范涉及到的变化估计在于：

a. 对于规范本身的基本信息描述，预计有少量修改，包括Rest接口的关键基础属性说明。

b. 对于输入和输出，不需要大变化，仍然保持当前的表格化格式定义，可以直接转换映射到资源对象。

c. 增加输入和输出的详细数据示例，是体现在Word文档，还是管控平台自动生成实例格式？

d. 增加错误码定义和描述，该段落为当前主流的OpenAPI平台具备的内容

也就是说，我们完全可以做到一套服务规范来支撑SOAP和Rest接口，毕竟在做跨系统间接口服务集成的时候，这里的接口更多都是粗粒度的服务定义，并不会涉及到细粒度的数据表或对象的所有CRUD操作。也就是跨系统间的接口更多的是满足跨业务协同和数据集成需要即可，是横向系统和系统之间的接口，而不是类似单个业务系统展现层和逻辑层到DB层的接口。

对于Http Rest接口，传递的数据要支持XML和Json两种格式，这个也需要提前进行约定和配置。而为了兼容当前的服务规范格式，可以看到这样转过了的Rest接口方法全部为Post接口，同时接口服务名即为资源对象名，同时在接口调用的时候传递的是一个我完整的数据集合对象。这和我们前面讲Rest接口的设计和调用是有区别的。

规范定义讲清楚后，整个过程就简单了，原来已有的直接在界面上定义服务规范或者通过Word文档导入服务规范功能基本都可以保留，做少量变更修改即可。导入的规范本身也可以进一步导出或直接在线查看。

对于Rest接口服务，我们仍然可以遵循一样的契约先行和自顶向下设计的思路进行。

规范清楚后，接着还是需要导出标准的契约格式文档，而这里建议还是采用WADL，基于Rest接口的服务定义语言，有强契约格式要求。而对于RAML，更多是Rest接口设计建模的语言，类似于通过RAML来写文档。如果我们是以Word服务规范文档格式为主，实际上是没必要再用RAML。但是可以考虑服务规范导出RAML语言定义。

RAML(RESTful API Modeling Language 即 RESTful API 建模语言)是对 RESTful API的一种简单和直接的描述。它是一种让人们易于阅读并且能让机器对特定的文档能解析的语言。RAML 是基于 YAML,能帮助设计 RESTful API 和鼓励对API的发掘和重用,依靠标准和最佳实践从而编写更高质量的API。通过RAML定义,因为机器能够看得懂,所以可以衍生出一些附加的功能服务,像是解析并自动生成对应的客户端调用代码、服务端代码 结构, API说明文档。

这样也方便我们后面基于RAML来生成API定义文档。

在规范导出为WADL设计文件后，那么就有严格契约格式要求，业务系统可以基于该WADL定义文件，通过 工具 自动生成客户端和服务端的代码开发框架，然后再填充业务规则和逻辑，这个过程和我们标准的SOAP WS接口服务的设计和开发是一致的，并没有太多的区别。

在服务提供端按WADL要求开发后Rest接口服务后，由ESB进行服务代理封装接入，这个需要单独设计功能支持，即需要采用单独定制的OSB服务封装模板。在服务代理接入后，我们原来对于SOAP接口的安全，日志等控制能力全部都需要保留和平滑支持。

服务代理接入后，仍然自动化部署，部署完成后给出代理封装后的访问地址。

对于服务调用访问，本身也会产生日志记录，对于已有的服务运行日志监控，服务异常日志监控等功能，都需要完全平滑的支撑Http Rest接口服务。对于原有的日志元数据配置表，服务日志运行实例表等也保留一套。

2. 对于SOAP和Rest接口本身的转换映射问题

当我们采用同一套规范体系的时候，我们就很容易去实现两种类型接口的转换和映射。

业务系统如果提供的SOAP WS接口服务，我们需要单独提供一个功能，将该SOAP WS服务发布为Http Rest接口服务，同时在发布的时候可以选择是采用XML格式，还是Json格式进行发布。

这样好处就是原来业务系统以及提供了SOAP接口，但是当我们在对接一个微服务架构体系的时候，消费端为了自身的标准化需要消费Rest接口服务，那么由ESB来完成这种转换映射即可，原有的业务系统服务提供方不再需要做任何服务设计变更和代码修改。

当然，如果业务系统本身提供的Http Rest接口服务，为了对已有的历史系统进行支撑，我们也可以将Http Rest接口服务转化为SOAP WS服务再进行暴露。在转换的时候新数据格式只能够是XML格式。

3. 对于消息发布订阅，消息中间件的支持

对于消息发布订阅，我们采用Weblogic JMS消息中间件，但是将JMS能力适配后发布为SOAP WS接口服务。在Http Rest接口服务实施过程中，我们需要支撑将JMS适配后能力直接发布为Rest接口服务。

当然为了简化，该功能非必须，即我们可以考虑在ESB接口上做两次代理，即将ESB已经暴露的SOAP WS消息分发服务接口，通过Http Rest接口服务转换功能直接进行转换后二次发布。

对于JMS消息订阅端，本身走Java API接口进行消息消费，本身和服务采用SOAP还是Rest没有太大关系。

4. 对于Http Rest接口的纯代理接入

对于业务系统已有的HttpRest接口，如果不希望按严格的服务规范设计和契约先行的思路进行变更，我们也可以直接对已有的Rest接口进行纯代理接入，即ESB做完全的代理转发，不做任何的安全控制，输入内容消息头的解析，数据映射转换等。对于这类Rest接口服务，ESB总线只起代理转发作用。