How do their APIs compare?

These two projects operate at completely different layers and aren't really comparable as "APIs" in the same sense, but here's how each exposes its functionality:

freeok/so-novel: HTTP/Web API

So-novel exposes a web-facing HTTP API built on embedded Jetty servlets. The routing is centralized in WebServer.registerServlets(), which maps URL paths to servlet classes:

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

[src/main/java/com/pcdd/sonovel/web/WebServer.java:L38-L52]

Looking at BookFetchServlet as a concrete example, it's a classic REST-style GET endpoint using query parameters (url, format, language, concurrency), with input validation against allow-lists (ALLOWED_FORMATS, ALLOWED_LANGUAGES) and bounds-checking on concurrency before dispatching to a Crawler [src/main/java/com/pcdd/sonovel/web/servlet/BookFetchServlet.java:L20-L87]. The frontend consumes this via plain fetch() calls, e.g. the search API wrapper does fetch('/search/aggregated?kw=...') and returns JSON [src/main/resources/static/js/api.js:L11-L15].

So this is a synchronous, request/response, JSON-over-HTTP API aimed at a browser UI and human-triggered actions (download a book, check sources, etc.) — essentially a small CRUD-like service, not a library API for other Java code to embed (though internally classes like HtmlExtractor, SearchParser, LangUtils do form a Java-level internal API for the crawling/parsing pipeline).

lmax-exchange/disruptor: In-process Java Library API

Disruptor has no network-facing API at all — it's a low-latency, in-JVM concurrency library. Its "API" consists of Java interfaces and classes meant to be embedded directly in an application's threads:

• WaitStrategy — an interface defining how consumer threads wait on a cursor Sequence [src/main/java/com/lmax/disruptor/WaitStrategy.java:L18-L20]
• AbstractSequencer — base class coordinating gating sequences and cursor ownership, extended by producer-specific sequencers [src/main/java/com/lmax/disruptor/AbstractSequencer.java:L22-L26]
• MultiProducerSequencer — claims sequence slots for multi-threaded publishers [src/main/java/com/lmax/disruptor/MultiProducerSequencer.java:L26-L32]
• SequenceGroups — static helpers for managing groups of Sequence objects [src/main/java/com/lmax/disruptor/SequenceGroups.java:L22-L23]
• dsl.ConsumerRepository — associates EventHandlers with EventProcessors, part of the higher-level dsl package that wraps the low-level primitives into a more ergonomic builder-style API [src/main/java/com/lmax/disruptor/dsl/ConsumerRepository.java:L28-L30]
• InsufficientCapacityException — a stack-trace-free exception thrown on non-blocking tryNext() calls, optimized for the hot path [src/main/java/com/lmax/disruptor/InsufficientCapacityException.java:L18-L24]
• ExceptionHandlers — static accessors for a default ExceptionHandler [src/main/java/com/lmax/disruptor/ExceptionHandlers.java:L17]

This is a synchronous, method-call API optimized for throughput and memory-ordering correctness (note the jcstress concurrency stress tests validating volatile/VarHandle visibility semantics, e.g. [src/jcstress/java/com/lmax/disruptor/