How do their APIs compare?

These two projects aren't really comparable at the "API" level in a like-for-like way, since one is a self-contained web application and the other is a media-playback library, but here's what's visible from the retrieved code:

freeok/so-novel: a local HTTP/servlet API

So-novel exposes a small REST-ish API served by an embedded Jetty server, wired up in [src/main/java/com/pcdd/sonovel/web/WebServer.java:L15-L59]. registerServlets maps concrete servlets to endpoints such as:

• /book-fetch → BookFetchServlet
• /book-download → BookDownloadServlet
• /local-books → LocalBookListServlet
• /search/aggregated → AggregatedSearchServlet
• /download-progress → DownloadProgressSseServlet (Server-Sent Events)
• /config, /book-delete, /sources, /sources/check, /suggestion

This is a synchronous, servlet-based, single-process API meant to be consumed by the bundled WebUI's JavaScript client, e.g. [src/main/resources/static/js/api.js:L11-L15] calling /search/aggregated?kw=..., and [src/main/resources/static/js/api.js:L32-L36] calling /sources/check.

A representative endpoint, BookFetchServlet, shows the API's style: plain query parameters (url, format, language, concurrency), manual validation against allow-lists (ALLOWED_FORMATS, ALLOWED_LANGUAGES), and JSON-ish error responses via RespUtils.writeError with HTTP status codes like 400/500 [src/main/java/com/pcdd/sonovel/web/servlet/BookFetchServlet.java:L18-L64]. It's a thin HTTP surface over an internal Crawler class that does the real work [src/main/java/com/pcdd/sonovel/web/servlet/BookFetchServlet.java:L69-L87].

So the "API" here is: a handful of GET endpoints on a local Jetty server, driven by request parameters, no formal schema/versioning visible in the retrieved code, and no authentication apparent in these snippets.

google/exoplayer: an in-process Java library API

ExoPlayer's public surface is a set of Java classes/interfaces consumed by Android apps in-process — not a network API. The retrieved chunks are mostly extension "library" classes such as FlacLibrary, Gav1Library, FfmpegLibrary, which follow a consistent pattern: a class that "Configures and queries the underlying native library" (JNI wrappers around native decoders) [extensions/flac/src/main/java/com/google/android/exoplayer2/ext/flac/FlacLibrary.java:L20-L29], [extensions/av1/src/main/java/com/google/android/exoplayer2/ext/av1/Gav1Library.java:L20-L29], [extensions/ffmpeg/src/main/java/com/google/android/exoplayer2/ext/ffmpeg/FfmpegLibrary.java:L24-L34].

Every one of these classes in the retrieved data is marked @Deprecated, with Javadoc pointing users to migrate to androidx.media3, since com.google.android.exoplayer2 is deprecated — this is a strong, explicit versioning/deprecation signal baked directly into the API surface itself, which so-novel's API has no equivalent of.

ExoPlayer's RELEASENOTES.md also documents an extensive history of API evolution — annotation renames (@FragmentedMp4Extractor.Flags, @RendererCapabilities.*, etc. [RELEASENOTES.md:L1064-L1098]), method renames (DecoderCounters#inputBufferCount → queuedInputBufferCount), visibility changes (SimpleExoPlayer.renderers made private), and behavioral/track-selection API changes across releases like 2.16.1 and 2.17.0 [RELEASENOTES.md:L1099-L1127, L824-L863]. This reflects a mature, carefully versioned library API with a formal changelog process, in contrast to so-novel's CHANGELOG.md entries, which read as internal refactors (e.g., "抽取 applyCrawlSettings 方法简化重复 null 检查", "LangUtil