openlark-api

What problem does it solve?

Provides a clear, repeatable implementation and refactor workflow for adding OpenLark API endpoints, removing uncertainty about file layout, endpoint usage, builder patterns, and request option handling so contributors can deliver correct, consistent implementations quickly.

Core Features & Use Cases

• Crate and path mapping: maps bizTag → feature crate and prescribes the crates/{crate}/src/{bizTag}/{project}/{version}/{resource...}/{name}.rs layout with fallbacks for existing structures.
• Builder & transport conventions: templates for Body/Response structs and Builder patterns that must expose execute_with_options or send_with_options to forward RequestOption into Transport.
• Service chain & exports: guidance for adding service.rs chain entrypoints and mod.rs exports so client.<biz>.service()... chaining works across crates.
• DocPath tooling & references: a fetch_docpath.py script to extract request/response examples and a set of reference docs for file layout and standard examples.
• Use case: add a new OpenLark REST API implementation, align endpoints/constants, ensure RequestOption propagation for tokens and headers, and validate with formatting, linting, and tests.

Quick Start

Locate the API in api_list_export.csv, choose the correct feature crate per tools/api_coverage.toml, create Body/Response types and a Builder that implements execute_with_options forwarding RequestOption to Transport, add the file under the prescribed path and export it in mod.rs and service.rs, then run formatting, linting, and tests.