How do their APIs compare?

These two repositories serve completely different purposes and have essentially no comparable API design goals, but I can walk through what each actually exposes based on the code shown.

liyifeng1994/ssm: a traditional SSM web app, not a library

This project isn't designed to expose a reusable "API" in the library sense — it's a sample SpringMVC + Spring + MyBatis web application. Its "API surface" is really just the set of Spring MVC controller endpoints.

For example, BookController exposes three HTTP endpoints via @RequestMapping:

• GET /book/list — returns a view name "list" [src/main/java/com/soecode/lyf/web/BookController.java:L34-L40]
• GET /book/{bookId}/detail — returns a view or redirects/forwards depending on whether the book exists [src/main/java/com/soecode/lyf/web/BookController.java:L42-L52]
• POST /book/{bookId}/appoint — an AJAX/JSON endpoint returning a Result<AppointExecution> wrapped object [src/main/java/com/soecode/lyf/web/BookController.java:L55-L76]

The JSON responses are shaped by a generic Result<T> DTO with success, data, and error fields and two constructors (success case and error case) [src/main/java/com/soecode/lyf/dto/Result.java:L6-L28]. This is a simple, synchronous, request/response style API typical of Spring MVC — every call blocks, returns a view name (String) or a @ResponseBody object, and there's no notion of streaming, async composition, or backpressure.

Testing of this "API" is done via Spring's MockMvc, asserting view names, model attributes, forwarded URLs, and JSON content type, as seen in BookControllerTest [src/test/java/com/soecode/lyf/web/BookControllerTest.java:L42-L61].

reactivex/rxjava: a reactive streams composition library

RxJava's API is a large, deliberately-designed set of reactive types and operators, nothing like a web controller API. Core types include Completable (no value, just completion/error signal) [src/main/java/io/reactivex/rxjava4/core/Completable.java:L38-L106], plus Observable, Flowable, Single, Maybe, and newer Streamable types referenced throughout the JMH benchmarks (e.g. StreamableSkipPerf, StreamableCollectPerf).

Key API characteristics visible in the chunks:

• Functional-interface based construction, e.g. CompletableOnSubscribe exposes a subscribe()-style callback taking a CompletableEmitter for cancellation-safe event emission [src/main/java/io/reactivex/rxjava4/core/CompletableOnSubscribe.java:L17-L23].
• Explicit protocol contracts documented in Javadoc, e.g. Completable's sequential protocol onSubscribe (onError | onComplete)? [src/main/java/io/reactivex/rxjava4/core/Completable.java:L58-L61].
• An annotation-driven metadata system (@SchedulerSupport) that documents which Schedulers an operator/class uses, including special NONE and CUSTOM markers [src/main/java/io/reactivex/rxjava4/annotations/SchedulerSupport.java:L29-L38].
• Heavy operator surface (concatMapCompletable, skip, collect, etc.) each with dedicated internal implementations and JMH performance benchmarks tracking regressions/improvements across design iterations, e.g. StreamableSkipPerf tracking multiple optimization passes ("avoid whenComplete", "batch wip accounting", "sync bias via Claude Fable atomics") [src/jmh/java/io/reactivex/rxjava4/streamable/StreamableSkipPerf.java:L24-L118].

The core contrast

Aspect	ssm	rxjava
API style	Imperative, synchronous Spring MVC endpoints	Declarative, composable reactive streams
Consumer model	HTTP request → view/JSON response	subscribe() with typed observers/emitters, async by design
Contract enforcement	Implicit (Spring conventions)	Explicit documented protocols (e.g. onSubscribe/onError/onCom