How do their APIs compare?

These two projects have fundamentally different kinds of "APIs," so a direct feature-for-feature comparison isn't quite apples-to-apples. Here's how they differ in nature and design:

codingapi/tx-lcn: internal protocol + annotation-driven API

tx-lcn is a distributed transaction framework, so its "API" is mostly aimed at other Java code, not HTTP clients:

• Annotation-based API for developers: The primary way application code interacts with tx-lcn is through annotations like @LcnTransaction [txlcn-tc/src/main/java/com/codingapi/txlcn/tc/annotation/LcnTransaction.java:L1-L13], which marks a method to participate in a distributed transaction. This is a declarative, AOP-style API rather than a REST endpoint.
• Internal SPI-style interfaces: Things like TransactionStep [txlcn-tc/src/main/java/com/codingapi/txlcn/tc/control/TransactionStep.java:L10-L17] and Commitor [txlcn-tc/src/main/java/com/codingapi/txlcn/tc/control/Commitor.java:L8-L14] define small strategy interfaces (type()/run(), type()/commit()) that plug into the transaction lifecycle (notify, commit, rollback steps).
• Custom wire protocol, not REST: Communication between the TC (transaction client) and TM (transaction manager) happens over a custom message protocol in txlcn-protocol, e.g. TransactionMessage [txlcn-protocol/src/main/java/com/codingapi/txlcn/protocol/message/separate/TransactionMessage.java:L18-L30] and TransactionNotifyEvent, dispatched via a TxManagerReporter as seen in TransactionStepNotify.run() [txlcn-tc/src/main/java/com/codingapi/txlcn/tc/control/step/TransactionStepNotify.java:L20-L55]. This is a socket/event-based protocol designed for low-latency coordination between distributed nodes, not a documented public HTTP API.
• JDBC interception layer: txlcn-p6spy embeds a fork of P6Spy providing JDBC event-listener hooks (JdbcEventListener interface, PreparedStatementInformation, etc.) so the framework can intercept SQL execution transparently — again, an SPI/interception API, not a service API.

So tx-lcn's "API surface" is: annotations for transaction boundaries, SPI interfaces for pluggable commit/rollback strategies, and an internal binary/event protocol for TC↔TM coordination.

xkcoding/spring-boot-demo: conventional Spring MVC REST APIs

The demos expose standard REST controllers meant to be called over HTTP:

• CodeGenController in demo-codegen exposes GET /table to list DB tables and POST "" to generate code and stream back a ZIP file, using @RequestBody, @RequestMapping-style annotations, and a uniform R response wrapper [demo-codegen/src/main/java/com/xkcoding/codegen/controller/CodeGenController.java:L26-L56].
• The underlying service (CodeGenServiceImpl) implements those endpoints by querying information_schema tables via raw SQL templates and returning paginated results (PageResult<Entity>) [demo-codegen/src/main/java/com/xkcoding/codegen/service/impl/CodeGenServiceImpl.java:L34-L131].
• Other modules follow the same pattern — simple @RestController classes like IndexController in demo-admin-client [demo-admin/admin-client/src/main/java/com/xkcoding/admin/client/controller/IndexController.java:L1-L14] — each demo module is a small, self-contained Spring Boot app with a conventional web API surface.

Summary of the comparison