Surpass turns SQL into guarded REST APIs

SQL statements become OpenAPI endpoints without controller code

Surpass attacks a specific gap: the cost of standing up an internal API platform. Its stated approach is zero-code development, where a developer writes SQL and the platform exposes that query as a RESTful OpenAPI endpoint. The implementation is a Spring Boot application that uses Mybatis for the SQL layer, and one configuration feeds both the running endpoint and the published contract. For a platform team, that means read only reporting endpoints, master data lookups and cross system queries can live in a console managed definition rather than in a separate controller class per screen. The trade-off is visible immediately. The endpoint shape is constrained by what a SQL statement and the OpenAPI configuration can express, so a request that needs several joined writes or a custom algorithm is not a natural fit for this path. Surpass is a way to publish the queries an organisation already runs, not a general purpose service authoring framework.

The user, role, application and resource chain behind every check

The permission model Surpass documents is the classic four part RBAC chain: user, role, application, resource. The console exposes separate screens for user management, role management, application management and resource management, which maps one to one onto that chain. Resources belong to applications, and roles collect resources, so the effective access of a client is the union of the roles it holds over the applications it targets. That is a sensible shape for an enterprise platform where one person may be an operator on one system and a reader on another. The README also names a client permission screen and a role permission screen, so access can be edited from either direction. Underneath, filtering is handled by sureness rather than by hand written checks in each controller, which is why the project describes itself as a stateless authentication and permission management system for REST API resources.

Client tokens, dynamic keys and JWT refresh on the request path

Authentication rests on a client token model. Each API consumer is registered as a client, and the token that client presents is what the platform checks before a request reaches the SQL layer. The README lists data transmission dynamic key encryption and JWT expiry refresh among the hardening features, so a token is not treated as a permanent bearer credential: keys are negotiated per request and JWTs can be refreshed. Token refresh is a real operational commitment, since clients need a refresh path and the platform needs a revocation story. The documentation does not describe how a revoked client or a rotated signing key invalidates outstanding JWTs, so anyone evaluating this has to ask the maintainers directly. The model is stateless in the sense that permission decisions are computed from the token and the configured resources, not from a server side session table.

No install command, so start from the db/ directory and the screen list

The README does not document an installation procedure, so there is no install command to copy and no documented way to bring the service up in a container. The project is reachable on two hosting sites, and the database schema travels with the code:

git clone https://github.com/dromara/surpass.git

What the README does give is a stack contract: JDK 17 or newer, MySQL 8.4.2 or newer, a Java implementation built on Spring Boot and sureness, and Apache-2.0 licensing. The repository layout is the practical starting point, with a db/ directory, a surpass/ directory for the server side and surpass-ui/ for the web console that backs every management screen. Because the database files ship with the project, the first step for an evaluator is to read db/ and confirm the schema matches the MySQL version in use. The console itself is documented only through screenshots: dashboard, data sources, clients, users, roles, applications, resources, OpenAPI configuration, an OpenAPI debug view, client permissions, role permissions and API call history. That list is effectively the feature map, and it is also the only inventory you get.

Call logs and Swagger output come from the same definition

Auditability is presented as a goal rather than an afterthought. The README says the platform records API addresses, the geolocation of callers, permission control decisions and user operations, and it surfaces that trail as an API call history screen. For a system where one team defines SQL and another consumes it, that log is the only way to answer who called which endpoint with which credential and what the permission layer decided. Swagger document generation is derived from the same OpenAPI configuration, which removes a manual step: a definition written once becomes both the running endpoint and the published contract. The OpenAPI debug view is the companion piece, letting a definition be exercised without writing a client first. A single configuration source is also a single point of failure. If the SQL behind an endpoint changes shape, the generated contract changes with it, and the documentation does not describe a version pinning mechanism for published endpoints.

One release and a recent push, with upgrade notes left open

Surpass is a young project with a short public trail. The repository lists a single release, 2.0.0, published on 2025-12-31, and the last push was on 2026-06-05, so code is still moving but the release history offers no evidence of a long compatibility track. The contribution path is an issue, fork and pull request workflow rather than a stated support model. The repository topics include JWT and Shiro related tags, which signals that the design draws on the Apache Shiro lineage of RESTful resource permissions and helps teams already running that model orient themselves. Operationally the documentation stays quiet on the details that decide adoptability: there is no upgrade path between versions, no schema migration story for the db/ directory, no clustering or failover notes, and no statement of which SQL dialects the Mybatis layer handles beyond the MySQL 8.4.2 requirement.

The alternative is writing the endpoints yourself in Spring Boot

The realistic alternative is to build the endpoints directly in Spring Boot with MyBatis mappers and enforce permissions in the service layer or with a general purpose security framework. The difference in approach is where the definition of an API lives. In the hand built route an endpoint is a Java class, so its contract, its SQL and its permission check are three things to keep in sync, and each new endpoint costs a developer. In Surpass the endpoint is defined in the platform's own SQL and OpenAPI configuration, the permission chain is applied centrally and the generated Swagger contract follows automatically. The cost moves from developer time to platform rigidity. Custom request handling, non-SQL business logic and elaborate response shaping all have to be expressed within what the configuration supports. For an internal platform serving a fixed catalogue of queries that trade is usually good, while a product team shipping arbitrary REST semantics will feel the limit immediately.

Editorial conclusion

Surpass suits an internal platform team that needs many read oriented REST endpoints, one RBAC chain shared across several applications and a call audit trail, and it fits best where Spring Boot, JDK 17 and MySQL 8.4.2 are already in place. It does not suit a product team that needs arbitrary endpoint semantics, or a team with nobody willing to own the db/ schema. Before adopting it, read the db/ directory and confirm the schema matches your MySQL version, then ask the maintainers how JWT revocation and key rotation work, since the project documentation is silent on both.

Frequently asked questions

Official sources

1. dromara/surpass on GitHub
2. Issues
3. License: Apache-2.0
4. README
5. Releases