Instant REST API for any database

Multi-Database Support

Switch your database with a single config parameter

GopServer natively supports the most popular relational database engines. Switching between them requires only a config file change — no code changes whatsoever:

• PostgreSQL (v12+) — default port 5432
• MySQL / MariaDB (5.7+ / 10.3+) — default port 3306
• SQLite — local file, no separate server, auto-created if missing
• Microsoft SQL Server (2012+) — default port 1433
• Oracle Database (12c R2+) — default port 1521, db_name = service name

All drivers are bundled in the static binary. Nothing extra to install on the server.

Automatic CRUD for Every Table

A complete API with zero lines of code

Define your tables in a JSON file and the server automatically exposes all required operations:

• GET /api/v1/{table} — paginated list (up to 100 per page) — always enabled
• GET /api/v1/{table}/{id} — single record by primary key — always enabled
• POST /api/v1/{table} — create a new record — requires allow_post: 1
• PUT /api/v1/{table}/{id} — partial update — requires allow_put: 1
• DELETE /api/v1/{table}/{id} — delete a record — requires allow_delete: 1

Write operations are disabled by default (HTTP 403). Enable only what each table needs. Adding a new table: edit tables.json, restart. Done.

Complete Authentication

JWT, session cookie and static token

GopServer supports three authentication methods, all configurable from app.conf:

• JWT (Bearer token) — recommended for mobile apps and SPAs; token valid for 24 hours
• Session cookie — for browser-based web apps; session lasts 3600 seconds by default
• Static token — never expires, ideal for server-to-server integrations; set via api_token in app.conf

Passwords are verified via SHA-512 with salt. The auth table, identifier columns and password column are fully configurable.

Use any existing table in your database as the user source — no special schema required.

Filtering, Sorting & Pagination

14 filter operators directly in the URL

All parameters are passed as query strings and can be freely combined:

• Pagination: ?limit=20&page=3 — default 10/page, max 100
• Sorting: ?sortby=price&order=desc
• Exact filter: ?category=Electronics
• Operators: gt, gte, lt, lte, contains, icontains, startswith, endswith, isnull and more
• Distinct values: ?distinct=category — great for populating dropdowns

Example: /api/v1/products?category=Electronics&price__lte=500&sortby=price&order=asc&limit=20&page=1

Built-in Security

Hidden fields, locked fields, per-table operation control

Control exactly what each column and each table can do via tables.json:

• hidden — excluded from GET + blocked at POST (e.g. password, salt)
• locked — cannot be changed via PUT (e.g. created_at, unique_code)
• hidden + locked — completely invisible and impossible to set via API
• allow_post / allow_put / allow_delete — set to 1 to enable, 0 to block. If omitted, defaults to 0 (blocked). Blocked operations return HTTP 403
• Tables not listed in tables.json are completely inaccessible
• Filters and sorts are validated against the allowed column list — SQL injection impossible through these mechanisms

The primary key cannot be changed via PUT or set via POST. GET is always allowed for any table listed in tables.json.

Raw SQL for Complex Queries

JOINs, aggregations, subqueries — when you need more power

When standard filters aren't enough, enable the raw SQL endpoint in app.conf (allow_raw_query = true):

• JOINs across tables — e.g. orders with customer data
• Aggregations: COUNT, SUM, AVG, GROUP BY, HAVING
• IN() filtering — multiple values for the same column
• Subqueries and complex SQL expressions
• Auto-enforced restrictions: SELECT only, semicolons forbidden, authentication always required

Recommended for dev environments or trusted internal users only. Keep allow_raw_query = false in production.