![]() | 1 murmur 2021-09-18 11:17:38 +08:00 现在的人都忘了 xml 么 |
![]() | 2 Itoktsnhc 2021-09-18 11:29:13 +08:00 主要就是共享 api 的定义嘛。要不 grpc 这种共享子模块,要不就有个 api 定义 ,然后有个 generator 生成 dto/entity,swagger 这种,然后考虑怎么自动化这个过程。 另外野路子就是 F# 的 TypeProvider,直接给你把各种定义在 coding 阶段给你动态的生成出来强类型。api 变了编译都过不去,还有很好用的智能提示。TypeProvider 可以为 CSV,db,甚至 CSS 这种,强类型的 CSS 怕不怕 |
3 gam2046 2021-09-18 11:37:41 +08:00 protobuf 和 grpc 并不强制绑定,可以单独使用 protobuf,另一个是 grpc 调试也不麻烦,可能是你相对来说没那么熟悉,刚开始有那么一个过程 |
![]() | 4 abcbuzhiming OP @murmur 怎么用 xml 生成跨语言的接口数据结构定义?不是直接用 xml 传递 |
![]() | 5 abcbuzhiming OP @Itoktsnhc 对,就是要考虑自动生成 dto/entity,swagger 这种,现在就是没有好办法自动化 |
![]() | 6 abcbuzhiming OP @gam2046 grpc 再不麻烦也比 REST Http 麻烦,这东西就是怕比。protobuf 直接通过编译生成接口和数据定义的方式我没找到,既有的手段都是依赖 grpc 本身的。 |
![]() | 7 aristolochic 2021-09-18 11:54:11 +08:00 ![]() grpc 主要是 protobuf 它就不是一个透明的序列化协议,为了性能和紧凑必须要定义 proto 文件,这不是顺便就解决了约束吗?另外也就有底气支持更加复杂的类型。而且这个约束还必须要遵守,如果不知道 proto 文件就是一坨二进制数据根本没法解析。而透明的序列化协议就压根不需要事先协商,不管谁传过来的都能直接用。这类序列化协议不一定非得是文本格式,msgpack 就是二进制版的 JSON 也可以直接用。也不是没有约束的方法,这个约束我们一般称为 Schema 要是说 Schema 的话,最先想到的估计就是 SGML/HTML/XML 那家子,从一开始就设计了 DocType 还有 Schema 。这些都是官方实现,用了好多年了相当成熟 但是也不是说 JSON 就没有了。JSON Schema 咋说也够用,还能提供更多的约束,要求更高还能自定义原语。比如上面提到的 Swagger 设计的 OpenAPI 3 spec 就是 JSON Schema 改的,不过定义了自己的原语实现更多约束,还重新诠释了 JSON Schema 规范中的一些字段(我是不太喜欢这么搞的,一下子就不兼容了 要是嫌 JSON Schema 不是官方 RFC 出的,那就次一点用 JSON Type Definition 。这个就没有更多的约束了,不过对于类型本身应该是比 JSON Schema 更细化,你想要指定 int 位数、有没有符号都行,而且还有一个 JSON Schema 里实现起来比较别扭的,就算不别扭也不一致,就是它能用 Discriminator 实现 Tagged Union / Sum Type 要说类型生成器,JSON Schema 和 JSON Type Definition 都有不少。如果是 Javascript 这种动态类型的也可以用流式 API 定义 JSON Schema 。XML 的 Schema 就更别说了,理应是更加成熟 (话说 ML/类 ML 语言社区搞的类型系统应用都挺魔怔的,印象里 Haskell 的 Yesod 有 CSS 、HTML 和 URL 等等等等的强类型。现在看来也不是只有 Haskell 这么狠 |
![]() | 8 Hconk 2021-09-18 12:46:25 +08:00 via iPhone 有个叫 gSOAP 的东西可以看看。 |
![]() | 9 masterclock 2021-09-18 13:16:32 +08:00 protobuf 不一定要 grpc,序列化后串口传输都干过 grpc 也不一定要 protobuf,用过 JSON 序列化的 grpc 总的来说,grpc 挺好用的,protobuf 有很多奇怪的缺点 |
![]() | 10 SingeeKing PRO 非要这么干,protobuf 定义 entity,protobuf 是有 canonical json 实现的,所以可以基于 REST 传输,跨语言什么的也都没问题 然而有什么意义呢,还不如直接上 grpc,生态很完善,联调其实并不麻烦 |
![]() | 11 SingeeKing PRO 「 protobuf 直接通过编译生成接口和数据定义的方式我没找到,既有的手段都是依赖 grpc 本身的。」??? https://developers.google.com/protocol-buffers/docs/javatutorial#compiling-your-protocol-buffers |
![]() | 12 wangbenjun5 2021-09-18 13:29:43 +08:00 人家用 protobuf 是为了节省资源消耗,加快服务响应速度,你为了约束接口?难道 http json 这种方式就不能约束了吗?我接口文档甩你,你按文档来就行了,如果文档和实际接口不一致那就是接口负责人的问题。 |
![]() | 13 lonenol 2021-09-18 13:41:26 +08:00 自己做一个开放平台,在开放平台定义接口和数据结构,两边分别实现自己的逻辑。。。 |
14 joesonw 2021-09-18 14:06:35 +08:00 swagger/openapi 是 http 的 |
![]() | 15 dk7952638 2021-09-18 14:24:22 +08:00 rest 天生就不适合处理复杂的关系 |
![]() | 16 ipwx 2021-09-18 15:28:39 +08:00 ![]() JSON 自己捏一套 我就自己捏了一套,满足 JSON + C++ |
![]() | 17 ipwx 2021-09-18 15:28:48 +08:00 满足 Python + C++ |
18 Wanyne 2021-09-18 23:34:12 +08:00 grpc-gateway,grpc 转 rest 接口,同时支持 grpc 和 rest api |
19 zartouch 2021-09-19 15:09:44 +08:00 json 的话 openapi 应对的 json 也可以做到啊。这个说白了就是 schema 校验么。 还有“ 一旦接口数据结构变动就会通过 protocol 文件让客户端和服务器都感知到” 这个其实是是需要客户端升级 api 版本才能做到的。何况有的变动是没法通过 schema 感知的,比如你的 date 是 string 格式从 yyyymmdd 改成了 yyyy-MM-dd 这个错误并不会在编译时报错。所以设计的 api 实际上肯定会向后兼容,breaking change 都会是新的 api 版本会直接在 rest api path 上面体现出来。否则就是设计的 api 本身的问题 |
![]() | 20 IvanLi127 2021-09-20 01:38:01 +08:00 via Android graphql ? |
![]() | 21 changwei 2021-09-21 02:11:53 +08:00 openapi 了解一下,3GPP 等技术标准化组织都是使用 openapi ymal 格式发布接口定义的,具体可以参考 ftp://www.3gpp.org/Specs/archive/29_series/29.551/OpenAPI/2018-12 |
![]() | 22 SmiteChow 2021-09-22 10:20:54 +08:00 看你描述核心就是想要 S-C 接口同步升级,和编程实现流程没关系,最简单的就是按照 RESTFull 规范升级资源版本号=>/api/v1.0.0/user 且不兼容旧版本接口 |