How do their APIs compare?

Poem and Pake aren't really comparable in the sense of "similar APIs" — they're solving completely different problems, and the "API surface" each exposes reflects that.

poem-web/poem — a Rust web framework, exposing a Rust extractor/handler API Poem's API is built around the #[handler] macro plus trait-based extraction and typed request/response handling. A few concrete surfaces visible in the retrieved code:

• ApiExtractor trait (used heavily by poem-openapi) — types that can be pulled out of a request implement from_request, expose TYPES (e.g. RequestObject vs Parameter), and contribute to OpenAPI metadata via request_meta() [poem-openapi-derive/src/request.rs:L119-L158]. This is the core "extractor" API pattern that's central to how handlers declare their inputs.
• Derive-macro-generated API metadata — poem-openapi-derive/src/api.rs builds up MetaOperationParam structs (name, schema, in_type, required, deprecated, explode/style) for each parameter, plus default/example value wiring, so the framework can auto-generate OpenAPI docs from ordinary Rust function signatures [poem-openapi-derive/src/api.rs:L332-L371, L412-L451].
• Type/schema registration API for objects — generated impls provide name(), schema_ref(), and register() so a Rust struct can register itself into an OpenAPI schema registry [poem-openapi-derive/src/object.rs:L373-L412].
• gRPC code-gen config API — poem-grpc-build::Config offers a builder-style API (btree_map(...), bytes(...)) mirroring prost's config, letting users control how .proto map/bytes fields map into Rust collections [poem-grpc-build/src/config.rs:L88-L167].
• Platform integrations like poem-lambda expose a Context extractor implementing FromRequest, so Lambda-specific data (e.g. request_id) is available in handlers the same way any other extractor would be [poem-lambda/src/lib.rs:L1-L33].

So Poem's "API" is a compile-time, trait/macro-driven surface for building typed HTTP/gRPC/OpenAPI services in Rust.

tw93/pake — a desktop app wrapper, no public web-framework API Pake isn't a library consumers extend via traits/handlers; its "API" is more configuration- and runtime-behavior-oriented:

• Build/config API — PlatformSpecific<T> provides a get()/copied() accessor that resolves to the macOS/Linux/Windows variant at compile time via cfg attributes, used for things like UserAgent and FunctionON type aliases [src-tauri/src/app/config.rs:L54-L79].
• In-page JS API — window.pakeFind is the closest thing to a consumer-facing API, exposing open, close, next, previous, search, getState, and getFindShortcutAction for the injected find-in-page feature [src-tauri/src/inject/find.js:L52-L68, L671-L677].
• Internal Rust helpers, like build_proxy_browser_arg, which format proxy URLs into Chromium CLI flags (e.g. --proxy-server=socks5://...), tested directly rather than exposed as a public API [src-tauri/src/app/window.rs:L793-L806].
• Dev tooling "API" — rollup.config.js defines a custom Rollup plugin (pakeCliDevPlugin) that spawns child processes to run the CLI and Tauri dev server together, which is a build-pipeline convenience rather than an app-facing API [rollup.config.js:L75-L136].

Bottom line: Poem exposes a rich, typed, macro-generated Rust API meant for other developers to build web/gRPC services on top of. Pake exposes a much narrower, mostly internal surface (a small in-page JS object, platform-config helpers, and build-tooling plugins) since it's an end-user desktop app packager, not a library. There's no meaningful one-to-one API comparison beyond both projects using code generation/config patterns (macros in Poem, cfg-based platform selection in Pake) to reduce boilerplate.