How do their APIs compare?

These two repositories aren't really comparable on an "API" basis in the same sense — one is a software framework with a programmatic API, the other is a curated list of third-party APIs. Let me lay out what each actually offers.

falconry/falcon — a web framework's API

Falcon exposes a Python API for building HTTP services, supporting both WSGI and ASGI:

• Request/Response objects: falcon/request.py defines a rich Request object with attributes like method, path, query_string, uri_template, and content_type [falcon/request.py:L158-L197]. It also supports media deserialization via get_media()/.media [falcon/request.py:L1158-L1170] and newer helpers like get_query_string_as_media() for OpenAPI-style querystring handling [falcon/request.py:L1173-L1197].
• Routing: The App class resolves routes through _get_responder(), which searches the router, maps HTTP methods to responder callables (e.g. on_get, on_post), and falls back to bad_request/path_not_found responders when no match is found [falcon/app.py:L1099-L1132][falcon/app.py:L1133-L1172]. The compiled router's add_route() maps HTTP methods onto resource methods, optionally with a suffix for multiple routes on one resource class [falcon/routing/compiled.py:L140-L179].
• ASGI-specific streaming API: falcon/asgi/app.py handles async response streaming, supporting async file-like objects, async generators, and async iterators, each written to the ASGI send() channel as http.response.body events [falcon/asgi/app.py:L817-L896].
• Utility introspection: helpers like is_python_func() let the framework distinguish native Python functions from Cython-compiled ones, useful internally for framework behavior that depends on function type [falcon/util/misc.py:L125-L148].

So Falcon's "API" is a code-level, request/response/routing programming interface meant to be imported and extended in Python code.

public-apis/public-apis — a directory of external HTTP APIs

This repo isn't an API itself — it's a Markdown-based catalog of publicly available third-party APIs, organized by category (e.g. "Development," "Authentication & Authorization") with a consistent table format: Title, Description, Auth type, HTTPS support, and CORS support [README.md:L529-L568][README.md:L240-L253].

• Entries follow a strict contribution format enforced by CONTRIBUTING.md, specifying accepted values for Auth (OAuth, apiKey, X-Mashape-Key, User-Agent, No) and CORS (Yes/No/Unknown) [CONTRIBUTING.md:L11-L48].
• There's even a validation script, scripts/validate/format.py, that programmatically checks entries — e.g. check_title() verifies the [TITLE](LINK) Markdown syntax and disallows titles ending in "API" [scripts/validate/format.py:L87-L106].

Bottom line comparison

• Nature: Falcon's API is a library interface you code against (classes, methods, request lifecycle hooks). public-apis' "APIs" are external web services merely cataloged — the repo's own "API" is just its Markdown/documentation structure plus a validation script.
• Depth: Falcon's API involves real behavioral contracts (async streaming, media handling, routing fallbacks) with lines of implementation logic. public-apis has no runtime API of its own beyond list formatting/validation tooling.
• Consumers: Falcon's API is consumed by Python developers building services. public-apis' listed APIs are consumed by anyone building apps against those third-party services (e.g. Auth0, Netlify, QuickChart) — Falcon itself isn't among them, but ironically, any of those listed APIs could be implemented using a framework like Falcon.

FOLLOW_UPS:

• How does Falcon handle ASGI response streaming internally?
• What auth types are most common in public-apis entries?
• How does Falcon's router match URI templates?