问题：
当前分为两种类型的接口，一种是给客户端使用的，一种是给其他服务使用的。 一个接口提供给外部使用之后，当要修改时，需要找到所有调用方。 问题是 不知道调用方是谁。
方案：
一个方案是 要求调用方传递一个标识，标识调用方是谁，如 appId/appName 。 该方案的缺点：
- 如果不强制传，调用方可能会不传
- 缺乏统一管理，只能通过日志筛选
另一个方案是 创建一个服务管理平台，当调用方需要用这个服务时，需要先在平台上创建，创建后生成 appId 或 appName ，然后调用方每次调用时传递该标识。 该方案的缺点：
- 有点麻烦，是否有必要
各位大佬们 当前都是怎么管理的
35 条回复 • 2022-01-30 08:58:09 +08:00
 |
1
Inn0Vat10n 2022 年 1 月 28 日  7
发邮件周知，然后一段时间后静默，等调用方找上门
|
 |
2
dapang1221 2022 年 1 月 28 日
appid/secret 方案不麻烦啊，代码都不用改，在应用的前一级加一个中间件就行了
|
 |
3
kekxv 2022 年 1 月 28 日 via iPhone
直接上新接口🐶
|
 |
4
Gota 2022 年 1 月 28 日 1
API 设计的时候就要考虑好升级时的兼容性, 如果是破坏性升级就得版本号 +1, 然后调用方自行决定是否升级.
每次升级都要使用者全改一遍一般很难维护下去. |
 |
5
lyz1990 2022 年 1 月 28 日 1
下线，等他们炸
|
 |
6
yazoox 2022 年 1 月 28 日
我的理解，有点像，某服务 /API 发布了一年，现在要修改该 API 的 bug ，或者参数变化。需要通知使用该 API 的客户，他们需要升级代码才能调用 API ，否则一旦 API 升级，那些客户的程序就不能工作了。
如果找不到那些“客户”，为了“向前兼容”，只能使用新的接口了 |
 |
7
jsion 2022 年 1 月 28 日
最直接的方法辨识客户端身份就是通过认证，密码认证 /Token 认证，不会说你们接口调用不需要认证?
这种场景直接用 Kong 做 API 网关就好了，连平台都不用搭建，里面有 consumer 的模块，帮你把用户跟踪、访问控制都可以统一管起来，只需要为调用方创建并提供 consumer 对应的 key ，调用方在请求头部设置就可以，要觉得需要修改用户请求数据，也可以通过网关插件来改，然后透传给后端服务。 |
 |
8
ffxrqyzby 2022 年 1 月 28 日
1 是通过 ip, agent 等肯定可以追溯到调用方进行沟通
2 是就像 ls 们说的周知邮件 |
 |
9
jinliming2 2022 年 1 月 28 日 via iPhone 6
API 不兼容的升级，那么为了平滑过渡，新 API 和旧 API 要同时存在一段时间，然后通知迁移，给个 deadline 。deadline 前几天检查旧 API 的流量，如果还有人在用，就给对应业务方发最后通知，过 deadline 下线旧 API 。
应用调 API 需要强制标记业务方，这个对管理有益，业务方请求肯定是有封装的，统一加个参数也不麻烦（要是请求没有封装，散落在各个地方，这不重构留着过年？） 现在业务方没传业务标记的话，不妨统一升级一套 API ，强制传业务标记。这样出问题也可以很容易定位到具体是哪个业务出的问题。 |
 |
10
strawberryBug 2022 年 1 月 28 日 via Android
1.链路追踪，可以拿到所有上下游服务的调用链路。
2.监控，从应用调用外部服务的监控数据里，反查调用方。 3.网关或服务网格记录上下游。 4.啥都没有就群发邮件，敦促各方自查吧。 |
 |
11
CEBBCAT 2022 年 1 月 28 日
为什么需要找到调用方呢？ API 的升级应该是兼容性地。
如果实在需要找到调用方，那么可以通过 HTTP 的 UA 、来源 IP 等来判断来源。 如果想用鉴权来解决，token 、JWT 都是可以的 |
 |
12
Vindroid 2022 年 1 月 28 日
新旧并存可以吗？旧版能用但不再维护，并公告
|
 |
13
yuancoder 2022 年 1 月 28 日
接口提供出去就不要改了，非要改就新加接口
|
 |
14
iGooner 2022 年 1 月 28 日
做服务鉴权
|
 |
15
jones2000 2022 年 1 月 28 日
加版本号， 老的版本接口和新的版本接口并存
|
 |
16
HENQIGUAI 2022 年 1 月 28 日
把接口下了，谁找你就说明谁调用了。
|
 |
17
liuzhaowei55 2022 年 1 月 28 日
1 、2 都要做，可以先从 1 次开始做，梳理下当前的接口使用情况，2 是进阶的做法。
当前可以先从源 IP 来大致区分一下，找一下上游应用。 |
 |
18
SmiteChow 2022 年 1 月 28 日
你这槽点，让我无处下嘴。还是问一下领导同事吧。
|
 |
19
qeqv 2022 年 1 月 28 日
旧接口不要有破坏性改动，有的话上新接口，如果一定要下线旧的再做调研。和领导同事沟通下再做，或者和提新需求的人
|
 |
20
512357301 2022 年 1 月 28 日 via Android
一楼说的发邮件，会不会调用方也不确定自己有没有用这个接口，毕竟接口挺多的
|
 |
21
dallaslu 2022 年 1 月 28 日
直接上 v2 。然后如果旧版接口有 err_msg 字段，附上一个 v1 deadline 提示
|
 |
22
psydonki 2022 年 1 月 28 日
可以考虑在服务的外层再套一层 gateway, 比如：Azure Application gateway, Amazon API Gateway
不同客户端调用不同 URL |
 |
23
ClarkAbe 2022 年 1 月 28 日 via Android
加 xss 获取域名，顺便获取浏览器 canvas 指纹，然后跳转公司首页
|
 |
24
SteveWoo 2022 年 1 月 29 日
那就强制传，不传报错，等对方找你就知道是谁了
|
 |
25
seanzxx 2022 年 1 月 29 日
前阵子 amazon 升级他的 smtp 服务，不然随机性的会报错，一天里面会看到 20 多次报错信息，里面包含了详细情况，我觉得也是一个好办法。
|
 |
26
ktqFDx9m2Bvfq3y4 2022 年 1 月 29 日 via iPhone
@HENQIGUAI #16 或者登报一周，没有人联系就可以放心换新 api 啦，哈哈。
|
 |
27
weakish 2022 年 1 月 29 日
@512357301 发邮件只是给别人提前改的机会，虽然别人其实也不一定清楚，但总比连改的机会都没有好。最好的还是保持兼容，但另一方面保持兼容也意味着增加了一笔技术债。
|
 |
28
w0017 2022 年 1 月 29 日
先公告，再关闭，然后看哪个 sx 找上门来。
|
|
29
w0017 2022 年 1 月 29 日
当然正常来说，是直接增加个 2.0 版，而非修改和删除 1.0
|
 |
30
bthulu 2022 年 1 月 29 日
下一版本标记为过时, 同时在 API 返回的消息当中提示这个接口过时了, 新接口文档地址是多少. 同时群发邮件通知. 然后在下下一版本直接移除
|
 |
31
ji39 2022 年 1 月 29 日
哈哈，人均大厂
|
 |
32
icegaze 2022 年 1 月 29 日 via Android
为啥对外的 api 不鉴权呢？
接口上要求用户 id 和密码加盐就行了，，， 这样每个进来的连接都有责任方啊， 也方便你们自己的业务做统计表(⊙o⊙)哇。 |
 |
33
libook 2022 年 1 月 29 日
企业生产的问题不是纯靠技术就能解决的了的，否则就不需要经理岗了。
这种问题就是约定规则和流程，拉所有相关方开个会，定好标准细节，以及责任划分（没遵守规定的要处罚），然后各方给个实施 DDL 。 |
 |
34
misaka19000 2022 年 1 月 29 日
通过 IP 地址找啊
|
 |
35
apgmer 2022 年 1 月 30 日
我理解 应该让产品经理去协调 (手动狗头)
|
• 请不要在回答技术问题时复制粘贴 AI 生成的内容