How do their APIs compare?

Based on what's retrievable from both repos, here's the comparison — with an important caveat: for ruoyi-vue-pro, my searches keep surfacing only its bundled SQL schema files and vendored third-party Liquibase/Flowable database-driver code (sql/dm/flowable-patch/..., sql/postgresql/..., sql/highgo/..., sql/opengauss/...), not its actual Java controller/service layer. So the ruoyi-vue-pro side of this comparison is inferred from its data-model shape (module-prefixed tables like infra_api_access_log, infra_api_error_log, infra_codegen_column) rather than direct controller code — I'd flag that as lower-confidence unless you want me to search more specifically for its controller module (e.g. yudao-module-system or yudao-module-infra controllers).

liyifeng1994/ssm — API style

This is a small, traditional SpringMVC teaching project, not a real "API" in the modern REST sense:

• Single @Controller (not @RestController) mixing view-returning endpoints and one JSON endpoint, all under /book [src/main/java/com/soecode/lyf/web/BookController.java:L27-L77].
  • GET /book/list returns a JSP view name "list" after populating a Model [src/main/java/com/soecode/lyf/web/BookController.java:L34-L40].
  • GET /book/{bookId}/detail returns view names, using redirect:/forward: string conventions for control flow instead of exceptions or HTTP status codes [src/main/java/com/soecode/lyf/web/BookController.java:L42-L52].
  • POST /book/{bookId}/appoint is the only JSON endpoint, explicitly annotated @ResponseBody with a hardcoded produces = "application/json; charset=utf-8" [src/main/java/com/soecode/lyf/web/BookController.java:L54-L57].
• Response shape is a hand-rolled generic Result<T> with just three fields: success, data, error — no standard error code, no timestamp, no pagination metadata [src/main/java/com/soecode/lyf/dto/Result.java:L6-L59].
• Error handling is done by catching domain exceptions (NoNumberException, RepeatAppointException) in the controller itself and mapping them to an AppointStateEnum embedded in the response body, rather than a global @ControllerAdvice/@ExceptionHandler [src/main/java/com/soecode/lyf/web/BookController.java:L60-L74].
• Business logic (transaction handling, exception translation) lives in BookServiceImpl, which converts checked exceptions into unchecked ones and logs at the service layer [src/main/java/com/soecode/lyf/service/impl/BookServiceImpl.java:L23-L80].

yunaiv/ruoyi-vue-pro — inferred API style

I can't show you its controller code directly from what's been retrieved, but the schema evidence points to a much more mature, enterprise-oriented API surface:

• Dedicated API observability tables — infra_api_access_log and infra_api_error_log — capturing request_method, request_url, request_params, response_body, user_ip, user_agent, duration, result_code, result_msg, plus full exception metadata (class, stack trace, root cause) [sql/postgresql/ruoyi-vue-pro.sql:L71-L110, L141-L163]. This implies a global request/response logging interceptor and a standardized result-code convention across the whole API, unlike ssm's ad hoc Result<T>.
• Multi-tenancy built into the API contract — nearly every table (including these log tables) carries a tenant_id column [sql/postgresql/ruoyi-vue-pro.sql:L90, L163], meaning API responses/requests are tenant-scoped by design — something entirely absent from ssm.
• Code generation infrastructure (infra_codegen_column, infra_codegen_table implied) [sql/postgresql/ruoyi-vue-pro.sql:L109-L118], suggesting CRUD controllers/DTOs for business modules are largely generated rather than hand-written like BookController.
• Consistent audit columns (creator, create_time, updater