Automatic REST API generation
Since v8.0 XavaPro automatically generates and publishes a REST API for all your JPA entities. You do not need to write controllers, DTOs, mappers, or configuration files: just write your domain entities with standard JPA and OpenXava annotations, and the REST API is immediately available.
The generated API includes:
- Full CRUD under plural URLs such as
/api/customers.
- An OpenAPI 3 specification and an embedded Swagger UI at
/api/.
- JWT authentication using XavaPro users, plus the same role, module, action, and field restrictions as the web UI.
- Pagination, multi-property sorting, and filter operators.
- Respect for
@Tab(baseCondition=...), History, email notifications, and multitenancy.
- Configurable CORS for browser-based frontends.
By default, the automatic API is turned off for security. You can easily activate it from the administration user interface without restarting the server.
Go to the Admin folder in your application menu and open the Configuration module. In the configuration form, check the Auto generate API checkbox and click Save:
Once checked, all endpoints under the /api/ path become active immediately. If unchecked, any incoming request to /api/* receives an HTTP 404 response with a JSON body {"error":"API is disabled"}.
XavaPro includes an embedded, offline Swagger UI explorer that allows you to inspect and interactively test every available endpoint directly from your browser.
To access Swagger UI, open the following URL in your browser:
http://localhost:8080/yourapp/api/
From the Swagger UI interface, you can click the Authorize button, paste the JWT (without the Bearer prefix; Swagger UI adds it), explore the JSON schemas of your entities, and execute queries directly against your application.
The raw OpenAPI 3.0 specification in JSON format is available at:
GET /api/openapi.json
The automatic API strictly enforces the same security model defined in XavaPro for the web interface:
- Module access: A user can only access an entity endpoint if their assigned roles have permission to view that module. Accessing a forbidden entity returns HTTP 403.
- Read-only modules: If a module is marked as read-only for the user or their role, only
GET requests are permitted. POST, PUT, and DELETE return HTTP 403.
- Action rights: Creating records (
POST) requires permission for the new action; updating records (PUT) requires permission for the save action; deleting records (DELETE) requires permission for the delete action.
- Excluded properties: Properties configured as excluded for the user's role are hidden from all
GET responses and ignored on POST and PUT.
- Read-only properties: Properties configured as read-only for the user's role are returned in
GET responses but ignored during PUT modifications.
You can create a dedicated api role (or multiple API roles) in the Roles module specifically for API consumers. Assigning this role to the API user accounts lets you fine-tune exactly which modules, actions, and fields are accessible through the REST API.
You can find all the details in the documentation.
|
