A flow can be exposed as a synchronous HTTP endpoint by declaring the verb and
path it serves; a REST resource is a set of flows, one per verb. The runtime
routes (method, path) to the flow, binds {path params} into the event, runs
it, and returns its respond. The OpenAPI document is generated automatically.
| File | Declaration | Endpoint |
|---|---|---|
orders_create.vjs |
api "POST /orders" |
create |
orders_get.vjs |
api "GET /orders/{id}" |
read |
orders_update.vjs |
api "PUT /orders/{id}" |
update |
orders_delete.vjs |
api "DELETE /orders/{id}" |
delete |
Each flow gets an event built from the request: the JSON body fields, the
{path params} (e.g. id), and query (the query string). It answers with:
respond <status>, { ...json body... }
respond is the synchronous HTTP response. A flow may still emit "subject", {…}
for asynchronous side effects on the bus — both happen.
POST /api/orders·GET /api/orders/{id}·PUT …·DELETE …GET /api/openapi.json— the generated OpenAPI 3.0 spec (paths, verbs, path parameters, request bodies, operationIds from the flow names, and the per-operation summary from each flow'stoolline).
Configure the spec's info via env: VEJAS_API_TITLE, VEJAS_API_VERSION,
VEJAS_API_DESCRIPTION. Writes honor VEJAS_TOKEN like the rest of the surface.
These demo flows are stateless (they echo). A real resource would invoke a
service that persists — e.g. through a database connector — while keeping the
routing/shape here as the editable business surface.
A flow may declare typed schemas as UPPERCASE literals — they feed the generated spec (and stay editable business surface):
API_REQUEST = {customer: "string", total: "number"} # -> requestBody schema
API_RESPONSE = {id: "string", status: "string"} # -> 200 response schema
Field types map to JSON Schema (string, number, integer, boolean,
array, object; unknown → string). Operations are tagged by their resource
(the first path segment), so tools group them per resource.