How do their APIs compare?

These two projects have almost nothing in common architecturally — one is a small embeddable rules-evaluation library, the other is a full microservices business platform. Let me lay out what "API" means in each context.

j-easy/easy-rules: a Java library API

Easy Rules exposes a small, in-process Java object API, not a network API. The core surface is:

• Rules — a collection you register rule objects into, e.g. rules.register(weatherRule) [README.md:L113-L116].
• Facts — a simple key/value bag of input data, e.g. facts.put("rain", true) [README.md:L108-L109].
• RulesEngine (with DefaultRulesEngine as the implementation) — the entry point that evaluates rules against facts: rulesEngine.fire(rules, facts) [README.md:L117-L118], also shown identically in the tutorial launcher [easy-rules-tutorials/src/main/java/org/jeasy/rules/tutorials/helloworld/Launcher.java:L31-L48] and the Maven archetype template [easy-rules-archetype/src/main/resources/archetype-resources/src/main/java/Launcher.java:L31-L48].
• Annotation-driven POJO rules — instead of implementing an interface directly, you can annotate a plain class with @Rule, @Condition, @Action, and @Fact, and the library wraps it via a dynamic JDK Proxy. RuleProxy.invoke() dispatches calls like getName, evaluate, execute, compareTo, equals, hashCode, and toString to the appropriate annotated methods on the target POJO [easy-rules-core/src/main/java/org/jeasy/rules/core/RuleProxy.java:L94-L118]. Facts are injected into condition/action methods by matching @Fact("name") annotations against the Facts map [easy-rules-core/src/main/java/org/jeasy/rules/core/RuleProxy.java:L163-L178].
• Rule identity/equality is derived reflectively from name, description, and priority [easy-rules-core/src/main/java/org/jeasy/rules/core/RuleProxy.java:L180-L203].

So "the API" here is a compile-time, embedded Java contract: you construct Rule/Rules/Facts objects and call fire() — there's no HTTP layer, no request/response DTOs, no auth.

yunaiv/yudao-cloud: HTTP/RPC service APIs across microservices

Yudao-cloud is structured as a multi-module Spring Cloud system exposing real network APIs between services:

• It defines RPC conventions via constants like RPC_API_PREFIX = "/rpc-api" and per-service prefixes (SYSTEM_PREFIX, INFRA_PREFIX), tying each prefix to a Spring spring.application.name (system-server, infra-server) [yudao-framework/yudao-common/src/main/java/cn/iocoder/yudao/framework/common/enums/RpcConstants.java:L10-L38].
• Cross-service calls use typed DTOs, e.g. ApiErrorLogCreateReqDTO annotated with Swagger @Schema and Lombok @Data, used for logging API errors between services [yudao-framework/yudao-common/src/main/java/cn/iocoder/yudao/framework/common/biz/infra/logger/dto/ApiErrorLogCreateReqDTO.java:L1-L10].
• Persistence and schema concerns (e.g. the DM8/Oracle-compatible Liquibase database driver code and SQL DDL for tables like infra_codegen_table) sit underneath these service APIs, supporting code-generation and infra tooling [sql/dm/flowable-patch/src/main/java/liquibase/database/core/DmDatabase.java:L281-L320, sql/dm/ruoyi-vue-pro-dm8.sql:L176-L215].

So yudao-cloud's "API" is a distributed, annotated REST/RPC surface (Swagger schemas, DTOs, service-prefix constants) meant for cross-service and client integration, backed by a database layer.

Bottom line

• Easy Rules: single-process, tiny object-oriented API (Rules, Facts, RulesEngine),