CSD 新版运价刷新接口开发规范
1. 如何使用
-
step1: 首先如果您接入过旧版的缓存刷新接口,可直接使用旧版的 AppKey 和 AppSecret。如 果未曾接入过,联系我们, 我们会给你们创建一个 App, 这个 App 对应着会有公钥, 私钥, 和一些对应的描述信息.
-
step2: 开发属于你们自己的客户端. 客户端参考 demo (Github 点击超链接). 基本概念等介绍参 考 Cerberus 文档 下面简单描述一下客户端做的事情:
-
- 通过 http 请求的 URI(比如获取 App 的操作: /api/app/getApp) + App key(公 钥) + 当前时间戳(一分钟以内, 最好当时生成) + AppSecret(私钥), 以上顺序不能 乱, 做 16 位的 Md5 运算, 会生成一个 sign.
-
- 每一个环境都有不同的 domain, 联调的时候用 FWS 测试环境, 生产上使用 production 生产环境, 请求 scheme 直接使用 http 请求, 不需要使用 https :
-
- 创建一个 Http 请求的 Request, 例如: scheme:http://, method:GET, domain:“cerberus.fws.qa.nt.ctripcorp.com” params: timeStamp, 第一步生成 的 sign, appKey, type:detail.
-
- 上面的 request, 拼接完成之后的 url,例 如:http://cerberus.fws.qa.nt.ctripcorp.com/api/app/getApp?timeStamp=15 91945072811&sign=fbe0994891ba3bf6&appKey=f3e97a6aewfn0cfa&typ e=detail. 如果是 POST 请求, 还需要带上 Http 的 Entity.
-
- 发出 Http request, 会有一个 response, 报文如下:
[
{
"name": "test service",
"description": "test service No.1",
"appCredential": {
"appKey": "4e827ce7c4685b4e8be",
"appSecret": "41357028d203041c53c1470854049b8cb40867b3de3a701038b5e38e5319ec6a",
"maxTokenCount": 10,
"validTime": 86400,
"datachangeLasttime": "2018-11-26 11:11:08"
},
"tokens": [
{
"tokenValue": "ac876821-f1f3-44a2-b05a-f02ce9d824f3",
"status": "alive",
"expire": 1543200293694,
"datachangeLasttime": "2018-11-26 10:43:27"
}
],
"tags": [
"owner_aphe",
"user_aphe"
],
"properties": [
{
"name": "status",
"value": "activated"
}
]
}
]
-
- 对上面的报文做反序列化, token 是一个 list 可能有多个, 可以根据有效时间排序 后, 获取生命周期最长的 token.
-
- 刷新缓存接口的访问地址, 也是区分测试环境和生产环境的, 测试环境前缀 : http://apiproxy-fws.ctripqa.com/apiproxy/soa2/19885/json/asyncRefreshCacheV2 生产环境前缀: https://apiproxy.ctrip.com/apiproxy/soa2/19885/json/asyncRefreshCacheV2
-
- 用过刷新缓存的访问地址, 测试环境: https://apiproxyfws.ctripqa.com/apiproxy/soa2/19885/json/asyncRefreshCacheV2 + 上面的 token + timeStamp(实时生成) + secret(私钥), 四个内容拼接完成之后, 做同 1. 中所描述的 MD5 加密, 生成一个 sign.
-
- 把 sign + timeStamp + token 加入到请求的 String 中, 得到一个最终的 URI, 例 如: https://apiproxy-
-
fws.ctripqa.com/apiproxy/soa2/19885/json/asyncRefreshCacheV2?sign=2a ebf9bd91ffa82a&timeStamp=1552632509159&token=qqqwwweeerrr
-
- 对该地址发送 POST 请求即可, 需要按照契约定义的要求, 带过来 json String 的 Http Entity (见下方接口契约说明).
-
- 按照业务契约对返回出去的 Response 做反序列化之后得到结果.
-
step3: 如上的一个 client 开发完成之后(建议参考 github 的 client demo) , 联系我们, 会打开一 个开关, 公司网关会放进来这样的请求, 就可以进行联调, 之后就可以使用了.
2. 接口契约说明
接口契约文档:https://developers.trip.com/flight/docs/supplier-ticket-offers-marketingsales-service/?lang=zhCN#tag/%E6%9C%8D%E5%8A%A1/operation/AsyncRefreshCacheV2
3. 其他注意事项
-
- 契约文档中 url 前缀为统一定义,无法调通,实际接口 url: 测试环境:
http://apiproxy-fws.ctripqa.com/apiproxy/soa2/19885/json/asyncRefreshCacheV2 生产环境: https://apiproxy.ctrip.com/apiproxy/soa2/19885/json/asyncRefreshCacheV2
-
- 供应商申请 APP 时,需提供票台 code。
-
- refreshLevel 支持全量推送(1、2)和部分推送(3、4)两种方式,接入全量推 送方式开发完成可联系我们开通线上开关;接入部分推送方式优先在测试环境接 入,联系我们,联调确认参数无误,再打开线上开关。
-
- 联系创建 App 前告知需要接入的推送方式,部分推送需要同时创建测试环境和 线上环境 App 信息。
-
- adultNumber、childNumber、infantNumber 这三个参数不确定的可传 1、 0、0,覆盖大部分情况。