iii 0.21：把任意函数变成 REST 端点的完整路径

iii 0.21把任意函数变成 REST 端点的完整路径【免费下载链接】iiiEffortlessly compose, extend, and observe every service in real-time for the first time ever.项目地址: https://gitcode.com/GitHub_Trending/mo/iii这篇文章带你用 iii 0.21 内置的httpworker 把一个普通函数绑定成一条 REST 路由启动引擎、注册函数、挂一个http触发器然后用一条curl命令拿到 JSON 响应。全程不需要 Express、FastAPI 或 Axum 这类 Web 框架跑完之后你会得到一条从curl到函数执行的完整闭环。最终结果在 3111 端口上 curl 一个端点先看目标形态。端点注册好之后调用它只需要一条命令请求直接打到引擎的 HTTP 端口默认3111curl -X POST http://localhost:3111/math/add -H content-type: application/json -d {a:2,b:3}预期行为返回状态码200响应体为{c:5}响应头含Content-Type: application/json。这里有个容易误解的点监听3111端口的不是你自己写的代码而是 http worker——一个项目级 worker由引擎按 engine/worker-compose.yaml 里的容器定义拉起来。你的 worker 只负责提供函数路由的管道是引擎给的。最小闭环从启动引擎到 worker add搭建只需要三条命令按顺序执行启动引擎若尚未运行iii --config config.yaml脚手架生成一个 workeriii worker init my-worker --language typescript指向 worker 目录把它加入引擎iii worker add ./my-worker执行成功后 worker 进程会被拉起并连接到引擎iii worker add http这类内置 worker 同理。这里要注意 engine/config.yaml 的分工config.yaml只放引擎生命周期内的内置 workeriii-stream、configuration等文件注释里明确写着http、state、cron、queue、pubsub、bridge这类项目级 worker 应放在worker-compose.yaml管理——iii worker add http的行为正对应后者。用一个触发器把函数绑到路由上worker 源码里只做两件事注册处理函数、注册http触发器。处理函数的入参是请求内容body、headers、method 等返回值经引擎拆解后成为 HTTP 响应。Node / TypeScript 版本import { registerWorker } from iii-sdk; const url process.env.III_URL; if (!url) throw new Error(III_URL must be set); const worker registerWorker(url, { workerName: my-worker }); worker.registerFunction(http::add, async (payload: { body: { a: number; b: number } }) ({ status_code: 200, body: { c: payload.body.a payload.body.b }, headers: { Content-Type: application/json }, })); worker.registerTrigger({ type: http, function_id: http::add, config: { api_path: /math/add, http_method: POST }, });Python 等价写法import os from iii import register_worker, InitOptions worker register_worker( os.environ[III_URL], InitOptions(worker_namemy-worker), ) def add(payload: dict) - dict: body payload[body] return { status_code: 200, body: {c: body[a] body[b]}, headers: {Content-Type: application/json}, } worker.register_function(http::add, add) worker.register_trigger({ type: http, function_id: http::add, config: {api_path: /math/add, http_method: POST}, })Rust 等价写法use iii_sdk::builtin_triggers::{HttpMethod, HttpTriggerConfig}; use iii_sdk::trigger::IIITrigger; use iii_sdk::{InitOptions, RegisterFunction, register_worker}; use schemars::JsonSchema; use serde::Deserialize; use serde_json::json; #[derive(Deserialize, JsonSchema)] struct AddRequest { body: AddBody, } #[derive(Deserialize, JsonSchema)] struct AddBody { a: i64, b: i64, } let url std::env::var(III_URL).expect(III_URL must be set); let worker register_worker(url, InitOptions::default()); worker.register_function( http::add, RegisterFunction::new(|req: AddRequest| { Ok(json!({ status_code: 200, body: { c: req.body.a req.body.b }, headers: { Content-Type: application/json } })) }), ); worker.register_trigger( IIITrigger::Http(HttpTriggerConfig::new(/math/add).method(HttpMethod::Post)) .for_function(http::add), )?;三种语言遵守同一份契约函数 id用http::add这种带命名空间前缀的命名触发器通过function_id与函数关联返回值映射status_code、body、headers三个字段分别成为 HTTP 状态码、响应体、响应头注意字段名是status_code不是status触发器配置只有两个关键字段api_path定路由http_method定方法。HttpTriggerConfig 源码字段逐条解读触发器配置结构体定义在引擎侧 engine/src/trigger_formats.rspub struct HttpTriggerConfig { /// HTTP endpoint path (e.g. /users/:id) pub api_path: String, /// HTTP method (defaults to GET) #[serde(default default_http_method)] pub http_method: OptionHttpMethod, /// Optional function ID to evaluate before invoking handler pub condition_function_id: OptionString, }字段级含义api_path路由路径支持/users/:id这类模式路径参数是内置能力函数入参里可以直接取到http_method可省略default_http_method()返回GET——不写就是 GET 端点枚举值覆盖GET/POST/PUT/DELETE/PATCH/HEAD/OPTIONScondition_function_id可选的前置函数 id引擎在调用处理函数前先求值它适合做路由级的前置校验对应引擎的 trigger 条件机制。同文件里还定义了响应信封HttpCallResponse对返回值缺失字段的行为有明确默认status_code省略时默认200headers省略时不带响应头body省略时返回空对象且会按你设置的Content-Type序列化为 JSON、文本或字节。默认端口 3111 的出处3111不是魔法数字在两处有依据。第一处是 engine/worker-compose.yaml 里 http 容器的配置块http: worker: package://api.workers.iii.dev/http version: 0.21.3 config_name: http config_override: port: 3111 host: 127.0.0.1 default_timeout: 30000 concurrency_request_limit: 1024 cors: allowed_origins: - http://localhost:3000 - http://localhost:5173 allowed_methods: [GET, POST, PUT, DELETE, OPTIONS]port: 3111就是curl里那个端口的来源host绑定127.0.0.1说明默认只在本机可达。第二处是 configuration worker 的配置模板语法${HTTP_PORT:3111}。engine/src/workers/configuration/store.rs 的测试里专门针对它做了断言port: ${HTTP_PORT:3111}这类模板必须先展开再做 schema 校验校验的是展开后的整数3111而不是把模板字符串当字符串放行——否则端口值会静默变成字符串类型。改端口和 CORS走 configuration worker 的运行时通道http worker 的服务器设置端口、host、CORS、超时不写死在 worker 定义里而是注册进 configuration worker运行时可改。按 docs/using-iii/configuration.mdx 的用法每个 worker 有独立条目http、state、queue……修改走触发器即可iii trigger configuration::get --json {id: http} iii trigger configuration::set --json {id: http, value: {port: 8080, host: 127.0.0.1}}预期行为set成功后新值按 schema 校验并生效http的 CORS、超时、端口这类设置多数在变更后立即应用无需重启 worker。配置值支持与config.yaml相同的${VAR:default}模板语法模板按原文存储、每次读取时重新展开所以换个环境变量就能换默认值。如何验证端点与常见排查除curl外console 的 Triggers 页可以直接验证左侧列出全部 HTTP 触发器方法与路径右侧有 TEST API 面板选方法和查询参数后点 SEND REQUEST 发真实请求底部同步展示该触发器的配置 JSONapi_path、http_method。等价的第二次curl验证换一组入参确认是函数在算而不是回显curl -X POST http://localhost:3111/math/add -H content-type: application/json -d {a:10,b:32} # 预期200响应体 {c:42}排查清单连接被拒先确认 http 容器在跑worker-compose.yaml里有没有 http 条目再确认端口没被占用改端口用上面的configuration::set或容器config_override404/打不中函数核对触发器api_path与方法是否和请求完全一致方法省略时默认GETPOST请求不会命中 GET 触发器响应与预期不符检查返回值三个字段名status_code拼错或缺省会落到默认200 空 body 的组合。四句话收束装什么iii worker add http由worker-compose.yaml的容器定义托管服务器管道归引擎怎么绑函数 { type: http, function_id, config: { api_path, http_method } }触发器一一对应默认值方法省略为GET端口3111、host127.0.0.1状态码缺省200去哪改端口/CORS/超时走 configuration worker 运行时configuration::set不用重新部署 worker。【免费下载链接】iiiEffortlessly compose, extend, and observe every service in real-time for the first time ever.项目地址: https://gitcode.com/GitHub_Trending/mo/iii创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考