rest
rest
Excalibase REST
Zero-configuration REST API from your database schema.
Point Excalibase REST at your PostgreSQL database and get instant REST endpoints — no controllers, no DTOs, no manual configuration. Every table becomes a resource, every column becomes a filterable parameter.
How it works
On startup, Excalibase REST introspects your PostgreSQL schema and generates route handlers for every table. The routes follow a consistent pattern:
| Route | Method | What it does |
|---|---|---|
/api/v1/{table} | GET | List rows with filtering, sorting, pagination |
/api/v1/{table} | POST | Insert a new row |
/api/v1/{table}/{id} | GET | Get a single row by primary key |
/api/v1/{table}/{id} | PUT | Replace a row (full update) |
/api/v1/{table}/{id} | PATCH | Partial update (only provided fields) |
/api/v1/{table}/{id} | DELETE | Delete a row |
/api/v1/{table}/{id1},{id2} | GET | Composite primary key lookup |
/api/v1/{table}/changes | GET | Real-time SSE stream (CDC events) |
ws://host/ws/{table}/changes | WS | Real-time WebSocket stream (CDC events) |
Everything — filtering, sorting, pagination, aggregations, relationship expansion — is controlled via query parameters. No request body schema to define, no OpenAPI spec to write by hand.
What you get
- 20+ filter operators —
eq,gt,ilike,in,is.null,jsoncontains, and more - Inline aggregations —
?select=count(),amount.sum()for instant analytics without extra endpoints - Relationship expansion —
?expand=customerincludes the related row inline - Cursor and offset pagination — both styles, configurable page size
- Composite key support —
GET /api/v1/order_items/1,2 - Column selection —
?select=title,rental_rateto return only what you need - OpenAPI spec — auto-generated at
/api/v1/openapi.json, importable into Swagger, Postman, or Insomnia - Real-time CDC subscriptions — stream INSERT/UPDATE/DELETE events via SSE or WebSocket, powered by NATS JetStream
Prefer: count=exactheader — opt-in exact row count for paginated responses
Performance
Excalibase REST adds 5–10ms overhead over raw SQL. The architecture is intentionally lean:
- HikariCP connection pool — queries go straight to the database
- Schema metadata cache — introspection only happens at startup, not per-request
- Query complexity analysis — prevents accidental full-table scans and runaway queries
Supported Databases
| Database | Status |
|---|---|
| PostgreSQL | ✅ Supported (PG 15+) |
| MySQL | 🔄 Planned |
| Oracle | 🔄 Planned |