How do their APIs compare?

This is a bit of an apples-to-oranges comparison since these two projects solve very different problems, but let's compare their API surfaces based on what's in the retrieved data.

mybatis/mybatis-3: SQL-mapping API

MyBatis's public API is dominated by declarative annotations that map Java interface methods to SQL statements. Key patterns visible in the data:

• Statement annotations: @Select, with variants like @SelectProvider, @InsertProvider, @UpdateProvider, @DeleteProvider — these let you either embed SQL directly (@Select("SELECT id, name FROM users WHERE id = #{id}") in [src/main/java/org/apache/ibatis/annotations/Select.java:L27-L39]) or delegate SQL generation to a provider class/method (@SelectProvider(type = SqlProvider.class, method = "selectById") in [src/main/java/org/apache/ibatis/annotations/SelectProvider.java:L31-L40]).
• Provider resolution convention: All the *Provider annotations (InsertProvider, DeleteProvider, UpdateProvider, SelectProvider) share an identical method()/databaseId() contract and fallback resolution logic via ProviderMethodResolver or a provideSql method — see [src/main/java/org/apache/ibatis/annotations/InsertProvider.java:L75-L90], [src/main/java/org/apache/ibatis/annotations/DeleteProvider.java:L75-L90], [src/main/java/org/apache/ibatis/annotations/UpdateProvider.java:L75-L88], [src/main/java/org/apache/ibatis/annotations/SelectProvider.java:L44-L59].
• Result mapping annotations: @Results/@Result let you declaratively bind columns to properties, including nested associations/collections via @One/@Many with lazy fetch types, as shown in [src/main/java/org/apache/ibatis/annotations/Results.java:L27-L40].
• Internal SQL representation: Underneath the annotation API, StaticSqlSource (implements SqlSource) represents a finalized, parameter-bound SQL string used at execution time — [src/main/java/org/apache/ibatis/builder/StaticSqlSource.java:L16-L26].

So MyBatis's API is fundamentally interface-and-annotation driven, oriented around mapping method signatures to SQL execution and result hydration. It's a synchronous, blocking, ORM-adjacent API.

spring-cloud-gateway: reactive HTTP routing/proxying API

Gateway's API is built around filters, routes, and reactive exchanges in a webflux (and webmvc) style:

• GlobalFilter implementations: Classes like ForwardRoutingFilter [spring-cloud-gateway-server-webflux/.../ForwardRoutingFilter.java:L36-L77] and FunctionRoutingFilter [.../FunctionRoutingFilter.java:L66-L145] implement GlobalFilter and Ordered, intercepting a ServerWebExchange and returning a Mono<Void>. These filters inspect the request URI scheme ("forward", "fn") to decide whether to act or pass through via chain.filter(exchange).
• ProxyExchange builder API: Both the WebFlux (spring-cloud-gateway-proxyexchange-webflux/.../ProxyExchange.java:L54-L115) and WebMVC (spring-cloud-gateway-proxyexchange-webmvc/.../ProxyExchange.java:L81-L120) variants expose a fluent, builder-style API (.uri(...), .get(), .post(), .header(...)) injected as a controller method argument — this is a very different paradigm from MyBatis's annotation-driven interfaces; it's imperative/fluent Java used inside @RequestMapping handler methods.
• Configuration-driven autoconfiguration: Classes like SimpleUrlHandlerMappingGlobalCorsAutoConfiguration [.../SimpleUrlHandlerMappingGlobalCorsAutoConfiguration.java:L1-L34] use Spring Boot's @ConditionalOnClass/