How do their APIs compare?

I want to clarify the term "APIs" here, since these two projects are quite different in kind, and answer based on what's actually shown in the retrieved data rather than speculate about unseen internals.

julien-cpsn/atac is a terminal API client (Postman-like), so it doesn't expose a public API for other programs to consume — its "API surface" is really its internal request/collection model and CLI. From the retrieved code:

• Request/import model: ATAC builds internal Request objects from external API specs. For OpenAPI import, it resolves $ref references for parameters and request bodies via resolve_parameter_reference [src/cli/cli_logic/import/openapi.rs:L270-L300] and process_request_body [src/cli/cli_logic/import/openapi.rs:L323-L412], mapping OpenAPI content types (application/json, application/xml, form-encoded, text/plain, text/html, application/javascript) into its own ContentType enum.
• Postman import: similarly, retrieve_query_params [src/cli/cli_logic/import/postman_collection.rs:L291-L310] converts Postman collection query params into ATAC's KeyValue structs.
• App state "API": the core App struct (in [src/app/app.rs:L79-L118] and its Default-style initialization at [src/app/app.rs:L199-L238]) exposes fields like url_text_input, query_params_table, and various auth_*_text_input fields representing the TUI's editable request model — this is effectively ATAC's internal "request-building API" that the UI and business logic layers operate on.
• Business logic methods: e.g. modify_request_auth_digest_domains [src/app/business_logic/request/auth.rs:L147-L161] shows the pattern used throughout — mutate a field on the selected request, log it, then persist via save_collection_to_file.
• CLI-level API: ATAC also generates a man page via generate_man_page [src/cli/cli_logic/man.rs:L7-L24], using clap_mangen against its Args clap command definition.

Per RepoPilot's import graph, src/app/app.rs is by far the most central file (94 importers), so it's the closest thing to a stable internal "API" surface for the app — and it's also part of several circular dependency chains (e.g. app.rs -> config.rs -> app.rs), which is worth knowing if you're trying to reason about how changes propagate.

sharkdp/bat is a CLI tool (a cat clone), and its "API" in the retrieved data is its command-line argument interface, built with clap:

• Argument definitions like --pager, --map-syntax, --ignored-suffix [src/bin/bat/clap_app.rs:L381-L420], --highlight-line, --file-name [src/bin/bat/clap_app.rs:L141-L180], and --force-colorization, --paging/--no-paging [src/bin/bat/clap_app.rs:L341-L380].
• These are consumed into a Config struct via App::config [src/bin/bat/app.rs:L308-L347, L548-L587], which resolves paging mode, style components, highlighted line ranges, etc.
• App::inputs [src/bin/bat/app.rs:L588-L627] builds the list of Input sources (stdin vs files), pairing user-supplied --file-name values with actual file paths.
• Internally, bat also has a library-facing "API" for syntax detection/assets (e.g. SyntaxDetectionTest tests in [src/assets.rs:L570-L609]), used for mapping file extensions/shebangs to syntax highlighting definitions.

Comparison:

• ATAC's "API" is a data-modeling API (requests, collections, auth, key-value pairs) plus import adapters translating third-party spec formats (OpenAPI, Postman) into its own model — it's stateful and TUI-driven.
• bat's API is essentially argument-parsing and configuration-building for a single-shot CLI invocation, plus a syntax-highlighting asset API — it's largely stateless per invocation.
• Neither repo, based on what's retrieved, exposes a network-facing or library-consumer-facing public API in the traditional sense (no REST/gRPC endpoints) — "API" for both really means internal Rust module interf