How do their APIs compare?

These are two very different kinds of "API" — one is a small, purpose-built task-submission API for driving Discord/MidJourney; the other is a broad admin/business-system RPC+REST layer. Here's how they compare:

novicezk/midjourney-proxy — narrow, task-oriented REST API

Shape: A handful of focused @RestControllers, each mapped to a short path segment, built with classic Spring MVC + Swagger (io.swagger.annotations) rather than newer SpringDoc/OpenAPI annotations.

• SubmitController (@RequestMapping implied by method-level paths like /imagine, /change, /simple-change, /describe) accepts DTOs (SubmitImagineDTO, SubmitChangeDTO, SubmitSimpleChangeDTO, SubmitDescribeDTO, SubmitBlendDTO) and always returns a uniform envelope, SubmitResultVO, with a numeric code, description, result (task ID), and an open properties map for extension fields [src/main/java/com/github/novicezk/midjourney/result/SubmitResultVO.java:L12-L63].
• TaskController is mounted at /task [src/main/java/com/github/novicezk/midjourney/controller/TaskController.java:L28-L32] and exposes read endpoints: GET /task/{id}/fetch, GET /task/queue, GET /task/list, POST /task/list-by-condition [src/main/java/com/github/novicezk/midjourney/controller/TaskController.java:L37-L59].
• AccountController is mounted at /account and exposes GET /account/{id}/fetch and GET /account/list [src/main/java/com/github/novicezk/midjourney/controller/AccountController.java:L18-L34].
• Validation is done manually and imperatively inside each handler (e.g., blank-prompt checks, banned-word checks, base64 format checks) rather than via bean-validation annotations, and errors are returned as SubmitResultVO.fail(ReturnCode.VALIDATION_ERROR, ...) instead of HTTP error statuses [src/main/java/com/github/novicezk/midjourney/controller/SubmitController.java:L58-L84, L109-L119].
• The API is essentially a thin façade over an internal task queue (DiscordLoadBalancer, TaskStoreService) that ultimately talks to Discord over a websocket connection (see SpringUserWebSocketStarter/SpringWebSocketHandler for the actual Discord gateway protocol handling) [src/main/java/com/github/novicezk/midjourney/wss/user/SpringWebSocketHandler.java:L194-L233].
• Auth is via a single shared secret header (mj.api-secret, per the README) rather than per-user accounts/roles.

This is a single-module, single-purpose API surface: submit an image job, poll/query it, query accounts. No pagination, no multi-tenancy, no RBAC in the API layer itself.

yunaiv/ruoyi-vue-pro — broad, modular enterprise API

The retrieved chunks for this repo are mostly SQL schema and vendored third-party (flowable/liquibase patch) source rather than controller code, but they still show important structural signals:

• It defines a distinct RPC API prefix convention, /rpc-api, in a shared constants class used across modules for internal service-to-service calls [yudao-framework/yudao-common/src/main/java/cn/iocoder/yudao/framework/common/enums/RpcConstants.java:L10-L18] — implying this project separates public REST APIs from internal RPC-style APIs, a distinction midjourney-proxy doesn't have at all.
• The schema reveals a much larger, multi-module business domain: e.g. infra_codegen_table/infra_codegen_column (a full code-generation subsystem that derives CRUD APIs from table metadata, including per-field flags like create_operation, update_operation, list_operation, list_operation_condition) [sql/postgresql/ruoyi-vue-pro.sql:L176-L214], and infra_api_access_log / infra_api_error_log tables that log every API call's method, URL, params, response body, duration, result code, tenant ID, etc. [sql/postgresql/