Restful API 接口模板化化生产和管理 (2)

需求的背景

** 核心resutful api 定义示例如下： **

• URL: /api/queryUsers
• 请求参数:

{
  "pageNum":1,  // 页码
  "pageSize":10, // 每页条数
  "userId":1,       //  用户Id
  "userName":"aaa"，// 用户名称
  "appId":[1,2,3],   // 使用平台
  "orderByColumn":"usedId desc"  // 以userId 进行倒序
}

• 响应结果:

{
  "status":0,        // 响应码 
  "pageNum":1,  // 页码数
  "pageSize":10, // 每页条数
  "pageTotail":10, // 总页面数
  "rowTotail":100,   // 总记录数 
  "users":   // 用户列表
      [
        {"userId":1,"userName":"aaaa","appId":[1,2,3]},
        {"userId":2,"userName":"bbbb","appId":[1,]},
        {"userId":3,"userName":"cccc","appId":[1,2,3]},
        ......
      ]  
}

** 业务api定义如下 **

• URL：/api/isExistUser // 查询用户是否存在

req：
{
"userId":"111" // 用户Id
}
resp:
{
"status":0,  //结果0存在，其他：不存在
"resson:"sfdf" // 错误描述
}

• URL：/api/getUserInfo // 查询指定用户信息(针对指定平台)

req： // 可针对用户id和用户名称进行查询，两个参数非必填
{
"userId":"111", // 用户Id
"userName": "aaaa" // 用户名称
}
resp:
{
"status":0,  //结果0存在，其他：不存在
"resson:"sfdf" // 错误描述
"user":{"userId":1,"userName":"aaaa","appId":[1,2,3]}
}

简单来说就是讲queryUsers转换为isExistUser和getUserInfo；isExistUser和getUserInfo实现其实都比较简单，无非就是修改下传入的参数和结果；
你可能会问这么简单的业务为啥还要包装呢?对外调用方直接修改参数不就行了？其实核心接口会随着业务增长开始增加接口或是对现有接口进行新参数的补充，调用方往往不会去全面评估说我们需要怎么传入参数，而是直接问你是这样传入么？业务接口做的其实就是外延把之前定义属于他们的管理的范围纳入到自己管理中避免上线出现业务业务对接出现问题。
随着对接方增加或是新业务增加，业务接口的数量也会开始增加；那么对业务接口也就需要管理体系对业务接口进行控制(核心接口的数量低于业务接口很多的，因为新合作方接入是常态肯定一下加3个合作方，每个合作方至少3个接口改造就9个了)

需要解决的问题:

OK，理清需求背景，我们现在做下需求的定位，也就是我们需要什么；
看如上的需求我需要的是两个东西：

1. 业务接口的管理工具
2. 核心接口转业务接口的工具

• 业务接口管理工具包括：对业务接口进行定义接口，查询接口，删除接口，生成接口定义代码
• 核心接口转业务接口的工具包括：

根据上第一篇需求进行项目设计如下图：

设计图初稿

设计图说明：

• 场景1: 程序猿定义可直接生产服务端源码；
• 此功能为能生成服务源码（包括业务），需要在定义过程中基本的Restful api定义(出参，入参)，还需要对入参进行校验定义，出参肯定出现合并定义定工作。
• 程序猿通过接口定义模块进行接口的定义的编辑工作，根据接口定义生成出对应的RestFul API接口(JSP源码)，然后对JSP源码进行入库操作
  • 场景2:程序猿自定义接口；
• 此场景也必须依赖场景1的定义，生成基本的jsp源码，再通过编辑修改此jsp源码完成自定义功能；
• 程序猿通过接口源码模块获取到已经生成好的RestFul API接口进行，对JSP接口源码进行手工编码后将
  • 场景3:业务调用接口，会先进入web的filter进行url的匹配过程，通过url获取到最新执行的源码，并在本地生产JSP源文件，最后调用此jsp返回执行结果