一个由登录接口引发的思考

一个由登录接口引发的思考

前言

我本以为，一个用户登录接口，虽可简单，可复杂，但一定是对调用者友好的。

以我从业十年的经验来看，一个好的登录接口，对于第三方调用者来说，只需要传入用户名、密码，返回登录是否成功、有无权限，而不必关心服务端内部的架构，至少我先前对接过的接口是这样的。

可近来在项目中的一次对接却完完全全颠覆了我的认知，这还是公司内部两个团队之间的对接。

登录方案

以A、B来代指这两方团队，B开发的一款数采软件需要向A开发的业务平台上传运维任务，按照常理，需要将任务本身的数据、以及操作者信息一同提交。

理想情况

经过A、B双方沟通后，决定按以下两步走：

1. 调用UserLogin验证用户名和密码，获取token
2. 调用SubmitTask，使用token提交任务

开发过程相当顺利，在测试环境中也成功提交了任务，一切都进行地顺风顺水。

不出意外的话，这篇文章也该到此为止了。

不出意外的意外

结果，意外很不出乎意外地来了。

当数采软件部署到现场对接生产环境时，得知生产环境跟公司内部搭建的测试环境完全不一样，大致是这样的：

在SSO单点登录的基础上，单独增加了云桌面、运维平台等模块。现场的运维人员会配备云桌面账号，但不一定有运维平台的账号，原先定的方案便行不通了。

A、B双方只得再次协商，得出了新的方案：

1. 调用UserLogin验证用户名和密码，获取token
2. 调用GetModuleId获取运维平台模块module_id
3. 调用ClouddeskLogin，使用前两步获取的token和module_id，换取desk_token
4. 调用OmLogin，使用desk_token换取最终有效的om_login_token
5. 调用SubmitTask，使用om_login_token提交任务

可是对于调用者来说，他应该考虑服务端的内部认证流程吗？

事已至此，即使B觉得这么做极其不合理也无济于事。修改代码后，算是实现了功能。

反思

功能虽然实现了，但也是B团队对A团队的妥协，从某种意义上说，是产品向项目的妥协。

A、B团队最初是从上下位一体化的角度出发，将业务平台与数采软件深度融合，打造一套完整的解决方案，并且向不同的客户推广。而现在的做法却跟当初的设计理念背道而驰，不仅没达成融合的目的，还给B团队进行打造的数采系统中引入了一系列不稳定因素，无法升格为产品，永远只能以项目形式存在。

举个例子，客户甲要求按照上面的架构部署，下次到了客户乙手里，砍掉了云桌面，换成了客户丙，再加了别的什么模块，是不是每次都要重新对接？

测试环境不能真实地模拟生产环境，即使公司内部测试好的代码，不能保证部署到现场后一定有用，在进行二次调整，那原先的测试流程还有什么意义？

作为调用者，消费接口时还需要考虑服务端的部署架构，甚至需要制动服务端内部的认证流程，这样合理吗？

在我看来，这是一种很糟糕的设计，没有之一。

设计接口时应当从方便调用者的角度出发，仅暴露输入、输出，调用者只需要知道结果，不用去关心过程。

以上面的方案来说，前四步仅是为了获取om_login_token，至于token、module_id、desk_token应该在接口内部处理，现在是提交运维任务，过段时间对接质控任务上传是不是再搞一套流程？

这还只是跟同一个系统的两个模块之间的对接！

写在最后

我所吐槽的，并不是接口本身。从更深层次看，公司内部多团队开发一整套解决方案时，缺乏一个强有力的产品经理，或者对上下位软件都有一定理解的架构师。要是在项目起步时就有一个整体的设计，划分好接口的职责，也许会有一个完全不同的开发体验。

作为一个小小的码农，人微言轻，提的建议没人采纳，公司说按现有方案做，那就这么做吧。

2022年11月2日星期三 于天霸