How do their APIs compare?

These two projects don't have comparable "APIs" in the same sense — one is a server-side web application demo, the other is a reusable Android threading library. Let me lay out the comparison concretely.

liyifeng1994/ssm — a web application, not a library

This project doesn't expose a reusable API for other code to consume. It's a demonstration SSM (SpringMVC + Spring + MyBatis) stack for a book-appointment system, and its "interface" is a set of HTTP endpoints defined by @RequestMapping annotations in controllers, e.g. BookController:

• GET /book/list → returns the list view [src/main/java/com/soecode/lyf/web/BookController.java:L34-L39]
• GET /book/{bookId}/detail → returns detail view or redirects/forwards if the book doesn't exist [src/main/java/com/soecode/lyf/web/BookController.java:L41-L51]
• POST /book/{bookId}/appoint → an AJAX/JSON endpoint returning a Result<AppointExecution> wrapped object, using @ResponseBody and a produces = "application/json; charset=utf-8" content type [src/main/java/com/soecode/lyf/web/BookController.java:L54-L72]

Responses are wrapped in a generic Result<T> DTO with success, data, and error fields [src/main/java/com/soecode/lyf/dto/Result.java:L6-L59], and appointment outcomes are modeled via the AppointStateEnum (SUCCESS, NO_NUMBER, REPEAT_APPOINT, INNER_ERROR) [src/main/java/com/soecode/lyf/enums/AppointStateEnum.java:L6-L37]. Persistence is handled through MyBatis DAO interfaces like AppointmentDao, which map annotated methods (@Param) to SQL statements [src/main/java/com/soecode/lyf/dao/AppointmentDao.java:L7-L28]. Its "API surface" is thus HTTP routes plus DAO/service interfaces internal to the app, tested via Spring's MockMvc in BookControllerTest [src/test/java/com/soecode/lyf/web/BookControllerTest.java:L30-L65].

reactivex/rxandroid — a small, focused library API

RxAndroid exposes a genuine public Java API meant to be imported by other Android apps:

• AndroidSchedulers.mainThread() — the primary entry point, giving a Scheduler bound to the main/UI thread.
• RxAndroidPlugins — a plugin/hook utility class letting consumers inject custom scheduler-handling behavior, referenced in [rxandroid/src/main/java/io/reactivex/rxjava3/android/plugins/RxAndroidPlugins.java:L1-L23].
• MainThreadDisposable — an abstract Disposable base class for building custom Observables that must dispose their resources on the main thread, exposing onDispose() for subclasses to override and a static verifyMainThread() helper, documented with a usage pattern example [rxandroid/src/main/java/io/reactivex/rxjava3/android/MainThreadDisposable.java:L1-L45].

This API surface is deliberately small and stable — it builds on top of RxJava 3's Scheduler/Disposable abstractions rather than reinventing them. The CHANGES.md shows recent API-level changes are conservative, e.g. version 3.0.1 just fixed a main-thread async-message check and bumped the RxJava3 dependency, without altering the public API shape [CHANGES.md:L9-L19].

Key contrasts

Aspect	ssm	rxandroid
API type	HTTP endpoints + internal DAO/service interfaces	Public Java library classes (Scheduler, Disposable, plugin hooks)
Consumer	Browser/AJAX client	Other Android app code, at compile time
Stability signal	RepoPilot analysis marks this repo WAIT — Stale, last commit 3 years ago, meaning even the internal structure should not be assumed to reflect current Spring/MyBatis best practice	Actively versioned with a changelog (CHANGES.md) documenting deliberate, backward-compatible API evolution
Testing style	MockMvc-based