REST in depth

api("items", "title, body") is the production CRUD helper. You name the resource and the text columns. Keel creates the table and the routes.

Names

name and each field must be a SQL identifier: letter or _, then letters, digits, or _. Comma-separated fields; spaces around commas are allowed. Illegal names are rejected and the resource is not registered.

Routes

Method	Path	Result
`GET`	`/api/health`	Liveness
`GET`	`/api/items`	All rows, `ORDER BY id`
`POST`	`/api/items`	Create
`GET`	`/api/items/:id`	One row
`PUT`	`/api/items/:id`	Update
`DELETE`	`/api/items/:id`	Delete
`OPTIONS`	those paths	CORS preflight

JSON body for create/update (curl, a file, or the browser: not a Buraaq string literal):

{"title":"First note","body":"Hello from Buraaq"}

Several resources

page("/", "public/index.html")
page("/about", "public/about.html")
api("items", "title, body")
api("users", "name, email")
run()

Limits: 16 APIs, 8 fields each, 32 pages.

`call`

use std.keel.call
body = call("https://example.com/api/health")

Keel can GET another HTTP/HTTPS API. Prefer this over rolling your own client for simple fan-out.

What you do not write

A router table
JSON serializer boilerplate for these columns
A CORS middleware file
A health-check framework

Those are why an API in Buraaq stays a screen of source and a native process: not a framework plus a container.

When api() cannot express the query, use `std.db`.