How do their APIs compare?

Since these two projects solve entirely different problems, comparing their "APIs" really means comparing two different kinds of interfaces: karumi/dexter's Java permission-request API versus proxyee-down's internal HTTP/JS bridge API used between its embedded browser UI and its local backend server. Here's a concrete breakdown:

karumi/dexter — a fluent, in-process Java API

Dexter exposes a builder-style, chainable API meant to be called directly from Android application code (Activities/Fragments). There's no network or IPC involved — it's just method calls on objects in the same JVM process.

• Entry point: Dexter.withContext(context) starts a fluent chain.
• Single permission: .withPermission(...), .withListener(PermissionListener), .check() — the listener receives onPermissionGranted, onPermissionDenied, and onPermissionRationaleShouldBeShown callbacks [README.md:L46-L56].
• Multiple permissions: .withPermissions(...) paired with a MultiplePermissionsListener that returns a MultiplePermissionsReport with helpers like areAllPermissionsGranted [README.md:L102-L114].
• Threading control: .onSameThread() to force callbacks on the calling thread instead of the default [README.md:L163-L173].
• Error handling: .withErrorListener(PermissionRequestErrorListener) surfaces a DexterError if something goes wrong internally [README.md:L187-L200].
• Composability: Provided listener decorators like BasePermissionListener, DialogOnDeniedPermissionListener, SnackbarOnDeniedPermissionListener, and CompositePermissionListener (and their multi-permission equivalents) let you compose behavior without subclassing everything from scratch [README.md:L61-L100, L118-L162].

This is a type-safe, synchronous-call/asynchronous-callback API — no serialization, no transport layer, just interfaces and builder objects.

proxyee-down — an HTTP + JS bridge API between processes

Proxyee-down's "API" is a set of local HTTP endpoints (backed by Netty, given the FullHttpRequest/FullHttpResponse types) combined with a JavaScript shim (runtime.js) that the embedded web UI uses to talk to the Java backend, plus a separate REST API consumed by the Vue front-end.

• JS-side wrapper (runtime.js) provides an ajax object with get/put/delete and async variants, all funneling through proxySend/proxySend2, which build an XMLHttpRequest and hit local ports (API_PORT, FRONT_PORT, REST_PORT) [main/src/main/resources/extension/runtime.js:L1-L23, L64-L103].
• Task creation is exposed via createTask/createTaskAsync, which serialize request, response, config, data as URL-encoded JSON query params and either call the local /api/createTask endpoint or open a front-end URL depending on uiMode [main/src/main/resources/extension/runtime.js:L104-L129].
• pushTask posts directly to a REST endpoint (/tasks?refresh=true) [main/src/main/resources/extension/runtime.js:L138-L140].
• On the Java side, ApiController.createTask is the actual HTTP handler backing this: it parses query params manually (splitting on ? and &) and forwards to DownApplication.INSTANCE.loadUri(...) to open the tasks UI, returning a bare 200 response with CORS headers [main/src/main/java/org/pdown/gui/http/controller/ApiController.java:L17-L47].
• Separate REST endpoints like /tasks and /util/resolve are referenced by error-code translation tables in the front-end i18n files, implying a JSON REST API with numeric error codes (e.g., 4000 "Params parse error", 4004 "Failed to create folder") [front/src/i18n/en-US.js:L141-L174].
• Ports are environment-specific, configured via YAML profiles: dev uses front.port: 8080, api.port: 7478 [main/src/main/resources/application-dev.yml:L1-L8], while prod disables the front port