How do their APIs compare?

Comparing "APIs" across these two projects means somewhat different things, since Kestra is an orchestration platform with an HTTP/REST API, while guide-rpc-framework is literally an RPC framework whose whole point is exposing Java interfaces as remote APIs. Here's how they compare:

Kestra: HTTP/REST API conventions

Kestra's API is a Micronaut-based webserver with explicit architectural rules documented in its contributor guide:

• Business logic separation: "No business code/rule inside controllers - instead use a Service class" — controllers stay thin [AGENTS.md:L129-L140].
• JSON-only responses: "All APIs must return a valid JSON object," and importantly, top-level responses should not be bare JSON arrays, to preserve backwards-compatible evolution [AGENTS.md:L132-L133].
• Validation: Input parameters must always be validated with @Valid [AGENTS.md:L138].
• DTOs: Requests/responses use dedicated DTO classes rather than exposing internal models directly [AGENTS.md:L137].
• OpenAPI documentation: APIs must be documented with OpenAPI annotations [AGENTS.md:L136].
• Async execution: Blocking operations must run on @ExecuteOn(TaskExecutors.IO) [AGENTS.md:L139].
• Security: Unit tests must assert authorization is enforced per-endpoint [AGENTS.md:L135].

Concretely, the CLI itself acts as an API client — e.g. PluginSearchCommand calls GET /v1/plugins and parses the JSON response into PluginInfo objects [cli/src/main/java/io/kestra/cli/commands/plugins/PluginSearchCommand.java:L22-L61,L62-L101], and AbstractApiCommand centralizes concerns like base URL (--server), auth headers (basic auth or bearer token), tenant-aware URI building (/api/v1/{tenant}/...), and a shared DefaultHttpClient [cli/src/main/java/io/kestra/cli/AbstractApiCommand.java:L28-L104]. KvUpdateCommand shows a typical write call: it builds a PUT request to /namespaces/{ns}/kv/{key} with content negotiation (TEXT_PLAIN), optional TTL headers, and value-type coercion via an ION mapper [cli/src/main/java/io/kestra/cli/commands/namespaces/kv/KvUpdateCommand.java:L30-L110].

So Kestra's "API" is a conventional stateless REST API: resource paths, HTTP verbs, JSON payloads, headers for auth/tenancy — consumed by both its own CLI and external clients.

guide-rpc-framework: RPC-style API

This project's "API" model is fundamentally different — it's not HTTP-based but Java-interface-based, using dynamic proxies so remote calls look like local method calls:

• Interface-driven: You define a plain Java interface (e.g. HelloService), annotate the implementation with @RpcService(group=..., version=...) on the provider side [README-EN.md:L132-L152], and inject a client-side proxy with @RpcReference [example-client/src/main/java/github/javaguide/HelloController.java:L10-L25].
• Dynamic proxy hides all networking, serialization, and load balancing — calling a method on the proxy transparently triggers the RPC machinery [README-EN.md:L75-L90].
• Synchronous and asynchronous variants: alongside the normal blocking proxy, you can obtain an async mirror interface returning CompletableFuture<T> via RpcClientProxy#getAsyncProxy [README-EN.md:L244-L272].
• Status/error model: instead of HTTP status codes, it defines its own RpcStatusCode enum deliberately aligned with gRPC's canonical codes (OK, CANCELLED, INVALID_ARGUMENT, DEADLINE_EXCEEDED, PERMISSION_DENIED, INTERNAL, UNAVAILABLE, etc.) [rpc-framework-common/src/main/java/github/javaguide/enums/RpcStatusCode.java:L11-L55]. Business failures surface as RpcServiceException; clients get a typed `