老哥 如果你想做简单的内网穿透 可以试试 www.1apm.com

每次我过隧道也有这个感觉 只不过高峰期隧道堵的跟狗一样, 平时隧道里也没人没车 感觉是因为国标卡着, 否则应该可以限速更快些

至于你说国标合不合理, 这个很难讲 从安全的角度上来说越慢越安全

可以试试 我闲时开发的 www.1apm.com

老哥 你要知道 这个学校是他喵的有 超算中心 的.... 镜像最贵的成本就是带宽, 然而几个破镜像的消耗带宽, 估计都不够超算中心这边的电费

如果你抽烟 不管你那封控不封控， 买个 4 条 放老婆那 之后忘记这件事

关键时刻能救命

可以的！ 之前用过 https://devdocs.io/ 但是感觉更新文档的比较慢

@channg 哦？ 主要我推送还是 ok 的 所以就没注意 web 端 我去整改

@hoythan

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

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



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

对接调试的时候可以试试我们的 nuapi ，会适当缓解对接的痛苦

@monmon 多谢鼓励 欢迎试用 nuapi 的其他功能哟

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

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

老哥, 可以试试我家的 nuapi 提供的 端口转发， 不需要安装额外的任何软件，0 配置， 只需 ssh 即可完成内网穿透 你可以参考下这个帖子 https://v2ex.com/t/841878

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

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

@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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

@Rache1

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


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

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

@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"}

```

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

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