网关需求文档规范

unirule ：所见即所得

业务背景介绍，增加能力及优化枚举

示例：增加/修改接口jd.union.open.xxx.xx.xxxx，增加/修改入参/出参字段xxx，在哪个（xxxInfo/根）结构下，具有xxx能力/用途，上线日期xxx.

1、需求类型，确认是哪种类型，新增接口还是修改接口

1.1 新增接口

1.1.1 确认是否是权限接口

1.1.2 确认api名称

     例如：jd.union.open.coupon.gift.get 礼金创建

1.1.3 确认出入参

1.1.3.1 入参字段命名

    （驼峰）、类型、是否必填、示例值、描述（如是枚举类，需穷举）；与上游哪些接口哪些入参字段映射使用

1.1.3.2 出参字段命名

    （驼峰）、类型、描述（如是枚举类，需穷举；如是单位，需标注）；与上游哪些接口哪些出参字段映射，需明确定义开放侧的字段归属在那一层级（data、各种info）

1.1.4 确认上游接口依赖

    接口文档、版本（GAV）、环境（alias）、测试请求、测试数据

1.1.5 确认接口使用场景

     用户数、调用量

1.1.6 sdk、http方式测试

1.2 修改接口

1.2.1 确认api名称

1.2.2 确认修改项

    具体的变动，新增/修改/删除，参照1.1.3

1.2.3 确定上游依赖

参照1.1.4

2、评审必须三方参与

产品、研发、测试，以产品的逻辑为准，研发依据逻辑开发，测试依据逻辑验证研发的功能是否符合产品的预期

需求文档中有3处及以上疑问不明确，评审不过。

3、上线发版日

openAPI发版上线计划，版本日16点之前必须提上线申请，否则顺延下一日，相关负责人总结延迟原因。

 

3.1产品提前走查，2天

4、上线需须知

新接口必须操作：

1）研发确认apiName

2）业务产品确认接口描述

实施方案

1、上游明确日期，提供GAV、文档（返回成功标识）、环境、数据，下游依据此开发

2、由cf同步，上游填写，下游开发前及时查看