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