How do their APIs compare?

These two projects expose fundamentally different kinds of "API" because they solve different problems (SQL mapping vs. RPC), but it's useful to compare how each turns a plain interface into a working call, since both rely heavily on dynamic proxies over user-declared interfaces.

mybatis-3: Mapper interfaces backed by dynamic SQL execution

MyBatis's primary public API is the Mapper interface pattern: a developer writes a plain Java interface (e.g. UserMapper) with methods annotated by @Select, @Insert, @ResultMap, etc., or backed by XML <select>/<insert> statements, and MyBatis generates a runtime implementation.

• MapperProxyFactory.newInstance(SqlSession) uses java.lang.reflect.Proxy to create an implementation of the mapper interface at runtime [src/main/java/org/apache/ibatis/binding/MapperProxyFactory.java:L45-L48].
• Calls are routed through MapperProxy.invoke, which dispatches to either a PlainMethodInvoker (wrapping a MapperMethod that runs the SQL) or a DefaultMethodInvoker (for default interface methods), caching the choice per Method [src/main/java/org/apache/ibatis/binding/MapperProxy.java:L57-L94].
• MapperMethod resolves which underlying SqlSession operation to call — selectOne, selectList, selectCursor, insert/update/delete, flushStatements — based on the SQL command type and method signature (return type, RowBounds, ResultHandler, etc.) [src/main/java/org/apache/ibatis/binding/MapperMethod.java:L87-L166].
• Configuration-level API (XMLConfigBuilder, XMLMapperBuilder) drives how settings, mappers, and result maps are parsed into the Configuration object that backs all of this [src/main/java/org/apache/ibatis/builder/xml/XMLConfigBuilder.java:L104-L129, src/main/java/org/apache/ibatis/builder/xml/XMLMapperBuilder.java:L102-L127].

So the "API surface" for a MyBatis user is declarative: annotations/XML describing SQL and result mappings, with SqlSession as the lower-level API underneath the generated mapper proxies.

guide-rpc-framework: service interfaces backed by network calls

guide-rpc-framework's API mirrors this "interface + proxy" idea but for remote calls instead of SQL. A client declares a service interface (e.g. HelloService) and injects it via @RpcReference, as seen in the example client [example-client/src/main/java/github/javaguide/HelloController.java:L10-L23]. Under the hood, a dynamic proxy (RpcClientProxy, not shown in the retrieved chunks but referenced by the annotation-driven injection pattern) serializes the call into an RpcRequest, sends it over Netty/socket transport, and returns a CompletableFuture-backed response.

• The socket-based transport client, SocketRpcClient, shows the async request lifecycle: submitting a request, scheduling a timeout via a ScheduledFuture, and cleaning up on completion or cancellation [rpc-framework-simple/src/main/java/github/javaguide/remoting/transport/socket/SocketRpcClient.java:L80-L119].
• Serialization is pluggable via SerializationTypeEnum (KRYO, PROTOSTUFF, HESSIAN) [rpc-framework-common/src/main/java/github/javaguide/enums/SerializationTypeEnum.java:L12-L37], and compression via CompressTypeEnum (GZIP) [rpc-framework-common/src/main/java/github/javaguide/enums/CompressTypeEnum.java:L12-L36] — both exposed as simple enum-based extension points rather than annotation-driven configuration.
• Extensibility more broadly uses an ExtensionLoader SPI mechanism requiring an @SPI-annotated interface type, with lazy, double-checked-locking singleton creation per extension name [rpc-framework-common/src/main/java/github/javaguide/extension/ExtensionLoader.java:L62-L95].