Generate a REST API From a JSON Schema (and Host It)
TL;DR: You can turn a JSON schema into a live REST API without writing backend code. Most tools that claim to do this only fake it or hand you client code you still have to implement. MoonDB takes a declarative JSON schema, builds a real database from it, and serves CRUD endpoints, auth, and file storage at a stable URL in three calls.
Why "generate a REST API from a JSON schema" usually disappoints
Search that phrase and you get three kinds of answers. None of them is a working backend.
The first is the mock generators. Tools like json-server read a JSON file and spin up routes in seconds. That is great for a quick demo. The data lives in a local file, there is no auth, and nothing is hosted. The moment a real user shows up, you have outgrown it.
The second is the spec-and-client crowd. An OpenAPI generator reads an OpenAPI document, which embeds JSON Schema for its data models, and emits a client SDK or a server stub. Useful work. But a stub is not an API. You still have to implement every handler, wire up a database, and deploy the result somewhere.
The third is the frameworks. FastAPI builds an OpenAPI schema out of your Python types, and Spring can scaffold controllers from a definition. Now you are writing the server again, just with nicer docs at the end.
The phrase hides a gap. People who type "generate a REST API from a JSON schema" want the schema to be the whole job. Describe the data once, get endpoints that actually store and return it. That final step, hosting a real backend, is the part the popular tools quietly skip.
What you actually want: schema in, hosted API out
Picture the flow you really had in mind. You write your data model as JSON. You send it somewhere. You get back a URL with working endpoints, and the row you POST today is still there next week.
Three things have to happen for that to be real:
- The schema becomes tables in a database, with types and constraints.
- Every table gets CRUD routes, plus filtering, sorting, and pagination.
- Auth and access rules exist, so not everyone can read everything.
Do only the first part and you have a migration script. Do the first two and you have an unprotected data dump that anyone can scrape or overwrite. You need all three before the word "API" earns its place in the sentence. The tools above each cover a slice. None covers the whole thing, which is why the search rarely ends well.
Generate and host a REST API with MoonDB
MoonDB is built around this one idea: the schema is the input, a hosted backend is the output. Here is the entire path for a small bookmarking app.
Step 1: create a project. One call returns the keys you need.
curl -X POST https://moondb.ai/v1/projects \
-H "X-API-Key: mk_your_account_key" \
-H "Content-Type: application/json" \
-d '{ "name": "linkstash" }'
{ "data": { "id": "p_8fz2", "admin_key": "sk_...", "public_key": "pk_..." } }
Keep the admin_key server-side and store it in an environment variable. The public_key is safe to ship in browser code.
Step 2: send the JSON schema. This is the part everyone is searching for. You describe the tables and fields in plain JSON and apply them with a single PUT.
curl -X PUT https://moondb.ai/p/p_8fz2/v1/schema \
-H "X-Admin-Key: sk_..." \
-H "Content-Type: application/json" \
-d @schema.json
{
"tables": {
"users": {
"columns": { "email": "string required unique", "display_name": "string" },
"auth_table": true,
"owner_field": "id",
"access": { "create": "public", "read": "owner", "update": "owner", "delete": "admin" }
},
"links": {
"columns": {
"user_id": "ref users required",
"url": "string required",
"title": "string max_length 200",
"tags": "string",
"is_archived": "bool default false"
},
"owner_field": "user_id",
"access": { "create": "authenticated", "read": "owner", "update": "owner", "delete": "owner" }
}
}
}
That JSON is the whole backend definition. The short strings carry the rules. "string required unique" becomes a non-null, unique, indexed column. "ref users required" is a foreign key into the users table. Setting auth_table: true turns users into a login table with hashed passwords and a set of /auth/* endpoints. The access block decides who can do what, and owner_field ties each row to the account that created it, so one user never sees another user's links.
MoonDB reads that, creates the tables, and starts serving immediately. There is no SQL to write and no migration file to babysit. Change the schema later and you send the new JSON. MoonDB diffs it against the current version and migrates for you, asking for explicit confirmation before anything destructive.
Step 3: use the generated API. The endpoints exist now. Create a row:
curl -X POST https://moondb.ai/p/p_8fz2/api/links \
-H "Authorization: Bearer <user-token>" \
-H "Content-Type: application/json" \
-d '{ "url": "https://example.com", "title": "Example", "tags": "reading" }'
Then read it back with a filter and a sort:
curl "https://moondb.ai/p/p_8fz2/api/links?is_archived=eq.false&sort=created_at.desc&limit=20" \
-H "Authorization: Bearer <user-token>"
{ "data": [ { "id": "...", "url": "https://example.com", "title": "Example", "tags": "reading", "is_archived": false, "created_at": "..." } ],
"meta": { "total": 1, "limit": 20, "offset": 0, "has_more": false } }
Three calls stood up and used the backend: create the project, send the schema, write the first row. The filtered read above is the generated API already working. A persistent REST API, generated from a JSON schema, with auth and per-user access already enforced. No handlers, no ORM, no deploy step.
What the generated API gives you
Defining a table does much more than create two endpoints. Each table arrives with a full set of routes and query features, all driven by the same schema.
| Capability | What you get |
|---|---|
| CRUD | GET/POST/PATCH/PUT/DELETE on /api/{table} and /api/{table}/{id} |
| Filtering | eq, neq, gt, gte, lt, lte, like, in, is_null, not_null |
| Sorting | ?sort=created_at.desc, and multiple sort keys |
| Pagination | offset for small tables, an opaque cursor for large ones |
| Field control | ?select=id,title and ?include=user_id to inline a related row |
| Bulk insert | POST /api/{table}/bulk, atomic, up to 100 rows |
| Auth | signup, login, refresh, and password reset on any auth_table |
| OpenAPI | GET /v1/openapi.json, generated from your current schema |
That last row matters if OpenAPI is what brought you here. MoonDB writes the OpenAPI document for you and keeps it in step with the schema. Point Swagger UI, Postman, or an SDK generator at it and you get typed clients without hand-maintaining a spec that drifts the day after you write it.
JSON Schema vs OpenAPI vs a hosted backend
These three terms get muddled in search results, and the confusion is worth clearing up, because it explains why the obvious tools fall short.
| What it is | What it does not do | |
|---|---|---|
| JSON Schema | A grammar for validating a JSON object's shape | Run anything |
| OpenAPI | A description of an HTTP API's paths and models | Host or implement the API |
| MoonDB schema | A declarative definition that becomes a live backend | Replace a high-write Postgres cluster |
JSON Schema and OpenAPI are documents. They describe. A MoonDB schema is also a document, but applying it provisions the database and the routes at the same time, so the description and the running system cannot drift apart. The schema is not paperwork about the API. It is the API.
When this is the right call, and when it isn't
A schema-driven backend fits when you want to move fast and the data model is the real work: an MVP, a side project, an internal tool, or an app an AI agent is scaffolding for you. The agent already writes JSON all day. Handing it a declarative schema keeps it on familiar ground instead of generating migration files it has no way to test. If you build inside an editor, MoonDB for Cursor walks the same flow from there, and the full schema and API reference covers every field type.
Be honest about the limits. MoonDB runs on SQLite through Cloudflare D1. You get fast reads at the edge and a simple model, with a single writer per database and a 10 GB ceiling, which is room for millions of rows in a typical app. For most early-stage projects that is plenty. If you are running a write-heavy system with thousands of concurrent writers, this is not a drop-in Postgres replacement, and a dedicated database is the better tool. If you are still weighing options, here is how MoonDB compares to Supabase. Choosing well early saves a painful migration later.
For everything in that range, generating the API straight from a JSON schema removes the slowest part of starting a project, which is building the backend at all.
FAQ
Can you generate a REST API directly from a JSON schema?
Yes. A declarative schema lists your tables and fields, and a service can turn that into live CRUD endpoints. Most tools stop at mocks or client code. MoonDB applies the schema to a real database and serves the API at a stable URL, so the endpoints store and return data instead of faking it.
What is the difference between JSON Schema and OpenAPI?
JSON Schema is a grammar for validating the shape of a JSON object. OpenAPI describes a whole HTTP API: its paths, parameters, and responses. They overlap because OpenAPI uses JSON Schema for its data models. Neither one runs your API. Both are descriptions you still have to implement or host.
Is json-server enough to generate a production REST API?
No. json-server is great for prototyping a fake API from a JSON file, but it keeps data in a local file and has no real auth, access rules, or hosting. It is a mock, not a backend. For anything users touch you need persistence and access control it does not provide.
Do you still need to write a database layer?
Not with a schema-driven backend. You describe the tables in JSON and the service creates them, handles migrations when the schema changes, and exposes typed CRUD routes. You write no SQL and no migration files. You send the schema, then call the endpoints it generated.
Sources
- json-server — file-based mock REST API generator
- JSON Schema — the validation vocabulary
- OpenAPI Generator — client SDKs and server stubs from an OpenAPI document
- FastAPI — generates an OpenAPI schema from Python types
- MoonDB documentation — the schema format and full API reference