目前已完成了PHP和js语言的客户端sdk v1.0.0 dev版本。 PHP版本uctoo-api-clientSDK开源项目地址[https://gitee.com/UCT/uctoo-api-client-php](https://gitee.com/UCT/uctoo-api-client-php) JS版本uctoo-api-clientSDK开源项目地址[https://gitee.com/UCT/uctoo-api-client](https://gitee.com/UCT/uctoo-api-client) uctoo-api-client-php 是一个轻量级、语义化、对IDE友好的HTTP客户端，支持常见的HTTP请求、异步请求和并发请求，是PHP开发者向UCToo服务端发送请求的SDK工具。 以访问微信小商店的标准版交易组件及开放接口为例。 我们开发了一个wechatopen标准微信开放平台前置服务器，wechatopen产品的作用是对接微信生态的所有API，同时以与微信官方API文档完全相同的调用方式和返回结果，以微服务的方式提供给需要对接微信生态API的客户端。（貌似wechatopen产品的作用和微信官方前几天发布的微信云托管作用类似，英雄所见略同） 与wechatopen标准微信开放平台前置服务器类似，目前还没有看到市面上有标准抖音开放平台前置服务器，可能也是可以试一试的产品方向。 言归正传，当我们要开发一个集成微信小商店的UCToo商城模块minishop时，在商品类目管理功能页面，有一个同步微信小商店获取类目详情的功能，我们就可以采用如下的开发规范：  *图1.minishop同步微信小商店获取类目详情* 1. 从前端VUE项目，发起一个请求给minishop产品的php后台同步类目接口sync。 2. 在php后台同步类目方法中，我们并不是按照传统的方式初始化一个本地运行实例的微信sdk去调用微信小商店标准版交易组件的开放接口，而是初始化一个uctoo-api-client-php客户端，转发请求到wechatopen产品的获取类目详情微服务。示例代码如下： ~~~php /** * 同步微信小商店类目数据到本地 * @time 2021年06月10日 20:29 * @param $f_cat_id */ public function sync(Request $request) { $result = null; $host = trim(Utils::config('wechatopen.host'));//获取管理后台配置的微信第三方平台地址 http://serv.uctoo.com $account = trim(Utils::config('wechatopen.account')); $password = trim(Utils::config('wechatopen.password')); $response = Http:: withHost($host) //指定第三方平台 ->withAccountAuth($account,$password) //采用服务端帐号认证 ->withVerify(false) //无需SSL验证 ->product('/api/wechatopen') //如果指定产品 则必填参数 ->post('/product/category/get', ['appid' => AdminApplet::adminApplet($request->user()->id)['appid'],'f_cat_id'=>0]); //当前管理员管理的appid $res = $response->body(); return CatchResponse::success( $res,'sync success'); } ~~~ *图2.minishop同步获取类目方法* 虽然在sync方法中，看起来比传统调用本地微信sdk方法多了几行代码，但是所带来的好处是非常巨大的。 uctoo-api-client可以指定第三方平台地址，可以路由到实现服务的产品模块，可以指定调用服务的商户帐号，可以指定调用具体的服务接口，所有这些输入的参数，都是可以在管理后台或模块的配置界面可视化配置的。这样就可以解耦wechatopen、minishop以及所有其他产品模块。产品之间的服务调用都是采用类似微服务的方式进行，可以实现服务访问与产品模块的部署方式无关，wechatopen产品可以是运行在UCT官方的serv.uctoo.com部署实例，也可以是部署在一些其他第三方平台或者大客户的第三方平台运行实例，而minishop产品模块的这段代码完全可以复用，进而为以后的可视化配置，低代码/无代码，工作流、服务编排等高级特性提供良好的基础设施。如果所有ISV都采用相同的开发规范，那实现SaaS产品之间的互联互通，产品模块在不同服务商间的商业化分发也是有可能的。 我们给这样的编程模式起个名字，就叫分布式服务总线吧，类似harmonyOS的分布式软总线。我们认为一切低代码/无代码应该至少在自身产品内部做到了标准的服务解耦，有统一的开发规范和产品模块作为标准的基础设施，就像微信小程序的云CMS和微搭低代码产品之间的关系，否则越做到后面越是复杂的业务场景，低代码/无代码产品本身反而会成为制约生产力发展的结点。 uctoo-api-client SDK结合我们上个月发布的API tester产品模块，给开发者提供了一个简单易用的SaaS应用开发基础设施。由于云原生时代的SaaS产品有越来越多需要和公有云集成和对接的地方，我们基本上把几个主流公有云提供商的开发文档和SDK都用过了。感觉目前只有某国内排名第一的公有云提供商，开发者门户中的文档、API在线测试工具、SDK形成了完整统一的标准体系，其他云提供商都还差点意思，要么是缺少API在线测试工具，要么是连统一的客户端SDK都提供不完整。大部分公有云服务商都还处在只管云不管端的初级阶段。比如，微信生态的在线调试工具，[https://mp.weixin.qq.com/debug/](https://mp.weixin.qq.com/debug/)，已经十年不变了，而微信开发相关的SDK基本是完全依赖第三方服务商和开源项目自由发挥。抖音开放平台至少每个接口都有在线调试工具。  *图3，微信调试工具* UCToo产品体系希望能够尽力做到端云结合，基于UCToo统一SaaS应用实例开发规范开发的产品可以云原生去中心化部署，又可以任意组合跨生态协同。 ## 更新日志 ### 2021-06-30 * 支持withHost * 支持product产品模块路由 * 支持withAccountAuth **Todo List** * \[x\] 异步请求 * \[x\] 并发请求 * \[ \] 重试机制 * \[ \] 支持http2 * \[ \] 支持OAUTH2 * \[ \] 支持openapi机制，可从服务端获取API信息，客户端即可快捷使用 GraphQL技术路线参考 [https://gitee.com/UCT/uctoo-api-client](https://gitee.com/UCT/uctoo-api-client) 技术选型 [https://github.com/apollographql/apollo-client](https://github.com/apollographql/apollo-client)