技术问题

1. 我们使用的编程语言不是 Python，怎么实现加解密协议？

由于 JWE 协议是 IETF 标准提案 RFC5861 JWE (JSON Web Encryption) ，有很多开源或者商业的函数库支持 JWE 加解密。下面列出各编程语言下支持 JWE 加解密的函数库，开发者可自行选择合适的函数库进行集成。

2. 为什么 Webhook API 不使用 HTTPS 协议？

原因一：常见的非双向认证 HTTPS 协议不能帮助开发者认证请求来自于百度，因而不能避免开发者数据被第三方抓取。由于我们的 Webhook API 是对公众完全开放的，如果仅使用常见的非双向认证的 HTTPS 协议，任意第三方都能用这个调用开发者接口获取产品数据。而双向认证的 HTTPS 协议又过于复杂，配置成本很高。

原因二：HTTPS 协议证书 TLS 握手过程耗时过长（2-RTT）。搜索请求对开发者的响应延迟要求非常高，花 2-RTT 的时间仅完成 TLS 握手代价过于昂贵，会导致实时请求完全不可行。

因此 OpenCard 的 Webhook API 采取了在 HTTP 协议之上使用预共享密钥的 JWE 协议，用 1-RTT 即可完成请求且能够保证双向身份认证和消息加密。

3. 压测请求被 WEB 服务器误识别为攻击流量，该怎么处理？

请将符合下列请求特征的压测请求添加到 WEB 服务器的防攻击豁免规则（白名单）中：

4. 我们能否修改 Webhook 协议格式？

Webhook 协议的 JWE 层加密协议、应用层的一些公共字段，是对所有开发者统一的。这样才能保证对每个开发者请求格式的统一，和响应结果处理的统一。

Webhook 协议的请求消息中 intent 部分，响应消息中 data 部分，每个卡片有自己的约定。对于该约定有疑问的开发者，可以通过下方反馈建议的方式提供自己认为更合理的修改建议。

5. JWE 协议开发过于复杂，有没有更简单的接入办法？

对于业务逻辑比较简单的 OpenCard 卡片，开发者可以使用 CFC Webhook 来接入 OpenCard。这种接入方式对开发的要求几乎是 0 成本。

但对于业务逻辑比较复杂的 OpenCard 卡片，建议开发者还是自己开发运维。