试图解决 “接口在我这里 ok， 为啥到你这就不行了！” 的对接问题

[atpking]

TLDR

NUAPI (www.nuapi.com) 的 域名转发可以辅助解决这类问题。

我们做了一个简单的视频， 可以让你快速了解我们是咋解决的 视频地址

如果你想试用一下 NUAPI www.nuapi.com ， 可以用这个邀请码注册 V2EXDOMAIN

另外 NUAPI 也有个不错的 端口转发 的功能可以参考这篇帖子 [内网穿透调试] 使用 NUAPI ，0 安装，5 秒钟拥有线上地址调试本地端口

正文

在我们软件开发的时候， 前后端经常遇到的问题是 后端自信的发布到测试环境后， 自己测试是没有任何问题的， 但是一旦到了前端测试的时候， 就遇到了各种各样的问题。

我这说几个常见的问题：

• 经常遇到的前端传参数与预期不同的问题
• 经常遇到的后端接口返回值与预期不同的问题

这些问题本质上来说解决起来比起技术角度，更多的都是所谓的“繁琐”。要找个大家都 ok 的时间， 把涉及到的人拉过来说明问题， 再等他们解决， 这是十分拖沓的。万一中途出了啥问题， 或者本身与某些人有过节,那简直是一场灾难。

其实我们转过头来想， 这些问题，是不是可以通过一些技术手段来解决？

我们最近研发了 www.nuapi.com ， 这里面的功能"域名转发" 可以较好的解决这些问题：

NUAPI 的域名转发原理

传统上，我们的访问 如下图所示

我们可以将 API 服务器 做一次 域名转发， 即 变为以下的访问流程

此时，nuapi 即可将访问的请求内容， 以及 API 服务器的返回接口， 均记录下来， 并且可以记录下来的请求的日志。

如何使用

首先在 NUAPI 中新建域名转发， 假设我的后端域名地址是 https://api.github.com

则我可以在 NUAPI 中的新建域名转发中填写

https://api.github.com/

创建完毕后，NUAPI 会返回代理域名

点击域名， 即可进入日志模式

我们会记录所有经过 nuapi 域名转发的所有请求， 以及请求后返回的 body 。这时， 如果我们想看看到底请求了什么内容， 则可以直接登录 nuapi.com 系统 进行查看。

这里还有一篇文章可以供大家参考 抓包工具 Charles 与 Nuapi 对比, 替代 Charles

当然， 知道自己传了数据， 收到了什么数据， 可以推测出可能出现的问题在哪里， 那有没有更好的方式来解决“在我这里跑 ok ， 为啥在你那不行”的方案呢？

有的， 就是我们的请求对比功能：

请求对比

经常出现这种问题： 后端用 POSTMAN 访问测试环境， 一切 ok ， 前端接入后， "请求跟 postman 一模一样，但是返回死活报错！“

此时我们可以用 NUAPI 的请求对比功能， 查询两者区别：

1. 首先让后端用 POSTMAN ， 将请求的 URL 的域名替换为 NUAPI 的转发域名，再次发送请求
2. 让前端或者 app 端， 进行相关操作 引起对应的 请求
3. 在 www.nuapi.com 中找到这两次请求， 之后点击 加入对比，nuapi 就会将两次请求的所有信息进行一一对比， 不同的内容我们就会立即显示出来

这样， 就可以轻易的看出， 这两个请求是否一样， 如果不一样， 是哪些内容部一样了

分享

当我们想把一条请求记录分享给其他人的时候， 只需要生成一个简单的链接即可， 不需要查看的人强制注册 NUAPI 用户， 仅拥有 URL 地址即可访问：

当使用分享链接打开地址的时候， 他会看到类似这样的界面， 此界面无需 NUAPI 即可查看

这样， 你可以轻松的将你认为有问题的请求， 发送给你的前端或后端。 这个分享详细的描绘了整个请求： 从请求的时间， 到请求的 header 参数，body 参数， 以及服务器返回的 header 和 body 。

结束语

NUAPI 是一个致力于帮助开发人员解决在开发测试的时候遇到的各种问题（包括内网访问、数据对比，mock 请求）的工具， 希望通过我们的这个产品， 能够为大家的开发期间的沟通带来顺滑的体验。欢迎大家试用， 目前 NUAPI www.nuapi.com 处在试用阶段， 所有功能均为免费， 大家可以使用 邀请码 V2EXDOMAIN 注试用， 有任何意见或建议可以在本贴留言，我将持续关注。

NUAPI www.nuapi.com 的技术栈为 前端 Vue3.2 ， 后端 Ruby on Rails + 少量 Node ， 使用 K8S 部署在阿里云上。也欢迎大家交流技术实现部分的问题。

[Kerwin1202]

端口转发

[auh]

非常不错。直接开源吧。核心理念就一个，找到了解决问题的常见策略。
直接性的优化了手动一点点扣日志的问题。扣来扣去就那么多。
不用直接扣了。我帮你做了。

这样的业务，是针对前段和后端对接的。实际上，这个没有发挥最大的价值。
因为，符合这样需求的不光是前后端。而且，最可怕的是，并没有那么多的问题，用这种方式来解决。

如果需要这种方式解决，个人觉得不是为了解决问题而解决问题，而是直接规避掉这种问题。

如何规避这种问题？规范，约定，强制校验。等等去他大爷的。
人啥也不用做了。功能被限制在最小的范围。利用一下，计算机达不到的能力。仅仅是高效思考。

养猪吃肉，猪还要啥自由？

[atpking]

@auh

老哥， 这个其实我们后面打算慢慢向 apigee 方向上靠， 做 API 的包装。

规范啥的都挺好的，写强校验， 靠规定啥的确实可以从本质上杜绝这些问题，只是确实太麻烦了，一旦麻烦， 人就想偷懒

NUAPI 的目标是提供简单的工具， 尽量做到简单易用，不用很麻烦， 用几分钟就能解决战斗。


另外我们 NUAPI 这个在 remote 开发中，nuapi 的 request 分享有着意想不到的好用，包括我们自己开发 nuapi ， 就是用的 nuapi 自己的域名转发来进行调试的， 在遇到 500 后，里面的重试， 对后端非常友好， 完全可以脱离前端就能重放 500 请求本身， 非常利于找到具体的问题。

[wolfie]

保姆式迁就前端工具，导出一个 curl 就那么难么。

[3dwelcome]

看了一下 blog ，类似抓包和重发工具，确实可以开源，可以扩大影响力。

现在单纯的 To 码农业务不好做呢。前几年是没工具，现在工具是多的不知道如何选，总有替代的产品。

从商业角度，如果卖的是服务，必须联网，那代码都是可以开源的。至少前端部分的可以。

[Rache1]

😂 Laravel 官方提供了 Telescope ，直接全套解决

[atpking]

@wolfie 😄 老哥， 我是后端出生


之前我们一直都是让 前端导出 curl 的，只不过 curl 也有一些问题， 我这总结下：

1. app 端似乎不太方便导出 curl
2. curl 只保存了 请求的 body ， 和 path ， 并未记录当时的 Response 信息， 有时候调试并不是那么及时（特别是 remote 的时候），之后现场丢失了不太适合
3. curl 导出的内容通常会有很大一串， 不太好一点一点的分析， 比如具体传了哪些 headers ，cookie 都有啥，会稍微乱一点
4. 也是我觉得最重要的部分：curl 不能做对比功能。 一般后端会用 postman 先验证一次， 前端在 app 端或者 web 端再发送的时候， nuapi 可以挑出两个请求， 之后逐次的对比， 这样可以立即发现传输的有啥不同。

举个例子

登录接口， 后端接口 是

```json
{"userName": "atpking", "password": "123456"}
```

前端传的是

```json
{"userName": "atpking", "passWord": "123456"}

```

不注意的话， 很难发现其中参数的问题

但是您看如果是这张图， 就非常容易知道问题出在哪里了


[micean]

我们已经通过后端开发来写 ts 接口的方式解决了这个问题

[hronro]

一个导出成 curl 就能解决的事情（浏览器 devtools 自带），非要去依赖一个第三方服务来解决。

还有怎么保证这个第三方服务不会抓取数据做一些非法的事情呢？

[atpking]

@Rache1

Cool ！ 看起来像是把日志里呈现的东西都展示出来了， 好像是基于 Laravel 本身的吧， 应该是通过在 php 服务器中插入啥实现的，功能很强大， 我看还有 queries ，cache 啥的统计。rails 好像也有类似的 gem ， 在管理端可以看到类似的信息。


我们这个 nuapi 做的是通用版本， 不依赖 具体的语言， 仅依赖域名。 等到用户需要上生产环境的时候， 将域名替换回来就好

更好的方式是 做一个开关， 可以切换域名， 这样哪怕是生产环境中，需要临时接入 nuapi 查看 bug 也可以打开开关切换 调试完毕后， 再切回原来的 API 域名

[atpking]

@hronro 您可以参看下 7 楼我的回复

关于“还有怎么保证这个第三方服务不会抓取数据做一些非法的事情呢？”

我们深知 我们保证 “我们不会在未经授权的情况下分享出数据” 在国内没有太大的意义

所以现阶段， 我们建议的建议是

"在开发， 测试阶段, 使用我们的域名转发"，

当产品进入生产环境时， 您可以将域名替换为正式 API 服务器域名，或者做一个开关, 在仅主动需要开启的时候再打开开关。

因为本身我们只是在域名上做一次修改， 对整体的程序没有其他的影响， 所以摘除掉 nuapi 是一件 0 风险的事情
另外我们的系统是基于 k8s 部署的（血泪史）， 如果您希望更彻底安全的使用的话， 我们乐于提供私有部署版本。

另外我们也在研究将转发与日志交由用户提供的服务器来进行操作，nuapi 本身只存储 id 值， 这样 nuapi 就只知道请求的 id ， 而不知道具体的内容了， 就可以做到安全又健康了

[Rache1]

@atpking 是的，不过您的这个确实相对来说比较小众，很容易被其他一些附属产品涵盖了，之前开发的时候也有过类似的问题，不过解决方案比较简单，就是通过添加 RequestId 的方式，记录请求到日志，前端只需要在出现问题时把 RequestId 反馈给后端去检查就可以了

其他层主说的导出 cURL 这个在浏览器里面确实比较方便，但是在原生的话可能就不太方便。

[hronro]

@atpking #11

看了下 7 楼的内容，给我的感觉还是像 typo 这些低级错误最好还是靠类型系统来解决，像 Restful 的话有 OpenAPI 之类的东西，或者直接用强类型的 GraphQL 。

至于重放请求这个还有点意思，不过我更倾向于这些东西应该放到 API Gateway 这一层来做。

[atpking]

@Rache1 嗯嗯 我们也有类似的 RequestID 的机制

其实我们这个工具还有一点就是 所谓的 不求人

很多时候， 直接自己就搞定， 我们前端发现请求 500 了之后， 直接就生成了一个分享链接扔给后端， 让后端自己玩去， 前端自己就通过 nuapi 直接 mock 接口的返回， 返回正确的结果就好了。

后端拿到分享的连接， 知道了前端传了啥 自己返回了啥， 等自己修复好了问题， 并重新上到测试环境后， 也不需要通知前端进行回归， 自己点击分享里的 重试按钮 nuapi 会自动的将之前的请求重新发送， 并将接口的返回展示给后端。如果不符合预期， 后端继续修改， 直到返回符合预期

这样就可以解决一个非常尴尬的问题：

后端吭哧吭哧的 修好了 bug ， 喊 app 端去试，app 端从 app 里进几个页面好不容易到了之前的 bug 点， 提交信息， 结果程序又返回 500 。此时 app 端是要骂娘的。

这个时候如果后端在分享的页面中点击重试请求， 是非常容易发现接口 500 的， 同时我们的重试并不是一股脑的啥都不能改， 而是 只是将之前的请求复制过来， 同时还可以编辑， 编辑完毕后再发送 这样后端还可以轻易的测测其他的情况是否都符合预期。

对接口这种事情， 特别容易引起矛盾， 有了 nuapi 的保障， 会让大家都觉得对方是个技术上靠谱的人

[wonderfulcxm]

我觉得这个项目还是很有意义的，一是可以把内网接口暴露到公网，对开发微信公众号这种很有帮助。二是日志和请求对比的功能，方便重现。

[atpking]

@hronro 是的 如果技术完备， 活不急的的话， 是完全没有问题的


可能是因为公司规模的问题吧， 我遇到的更经常的状态其实是 “急急急， 下周就上线， 赶紧的！” ，甚至连文档都没有， 接口直接 口头或者聊天工具上就交代几句， 全凭研发自己对， 这种情况就很尴尬

nuapi 其实就是轻量级的，去解决这些问题的工具。 这个工具几乎没有任何技术要求， 也没有啥学习曲线， 拿来就用， 只要用就能解决问题， 用完愿意扔马上就可以解除依赖。


ps：nuapi 其实还有个 beta 版本的功能， 就是根据你的请求， 自动的生成一份基础 OpenAPI 文档， 专门为 没有时间时间写文档的人使用 https://www.nuapi.com/docs/pages/bestPractices/backend.html#api-%E6%96%87%E6%A1%A3%E4%B8%8D%E7%94%A8%E4%BB%8E-0-%E5%BC%80%E5%A7%8B-%E5%AF%B9%E5%BA%94-uri-%E7%9A%84%E7%A4%BA%E4%BE%8B%E7%9B%B4%E6%8E%A5%E7%94%9F%E6%88%90%E5%A5%BD

[atpking]

@wonderfulcxm 多谢鼓励 欢迎免费试用哟

[atpking]

@hronro 是的 其实我们计划下一步就慢慢的靠向 gateway 的功能，独立出一部分进行开源，争取让用户在生产环境下使用

[wolfie]

@atpking
适用场景有点局限，比如联调时被请求服务需要扔到公网，生产环境依赖你们服务的稳定性。

如果能私有部署，可以作为不错的 debug 工具，前提足够多的额外 feature 。

做过异常日志的东西，java 切面做的，侵入式的，记录所有请求错误信息，也可以单个重试错误日志。
可以参考一下类似 skywalking 这种非侵入式的。

[hoythan]

"接口在我这里 ok ， 为啥到你这就不行了！" 我遇到过的 99%都是后端开发没考虑多任何异常的情况导致的.

[atpking]

@hoythan 是的 其实主要还是因为一般情况下我们都面临着 “产品急急急， 必须下周就上线” 的情况， 很多时候，甚至连 文档都没有，接口啥的几乎都是随便弄个文档写一写， 或者 im 中沟通一下就完

其实 nuapi 就是解决这些 时间不充分、技术配合较为麻烦的事情。

[atpking]

@hoythan

后端有时候就是懒的弄，或者压根不知道前端还能这么传， 用 curl 或者程序去构造一个测试环境太麻烦， 既然和前端对接， 不如就顺便让前端测一测。。。。。。

nuapi 的重发功能， 还是挺好用的， 可以 copy 之前的所有信息， 同时你还可以自己去改部分参数， 免去了再去 postman 去构造这个请求的麻烦



我们开发这个东西其实就是为了解决自己在开发中遇到的各种通痛点， 把枯燥乏味无聊的事情变的尽量简单点。