REST APIs

Why endpoints are nodes

In a typical framework, a route is a line of routing code plus a handler function you have to trace through separately to understand what it actually does. Fimaflow collapses that: the route definition and its full logic — validation, database access, business rules, response — are the same visible chain of nodes. Anyone looking at the canvas can follow a request from POST /orders to its response without reading a single line of code.

Defining an endpoint

An API Endpoint node has two required fields:

• • endpointMethod — GET, POST, PUT, PATCH or DELETE.
• • endpointPath — the route path, e.g. /orders/:id; path params like :id become available on the node's output the same way query params and the body are.

Connect it to whatever should happen next: validate the body, query the database, call an external service — then respond. Where several endpoints share a workflow, an Execute node marks the entry point Fimaflow uses to route the incoming request; its execOrder field decides which entry point wins if more than one could match. See Execution.

Responding to a request

A Response node closes the chain. Its two fields:

• • responseStatus — the HTTP status code, e.g. 200, 201, 404.
• • responseFormat — json by default; html and text are also available.

Whatever's connected into the Response node's input becomes the body. If an earlier node throws — a failed validation, a SQL error — the request never reaches this node at all; it short-circuits straight to whatever error handling you've set up (see Debugging). Without an explicit error path, a thrown error falls back to a 500 with the error message as the body — fine while prototyping, worth replacing with a deliberate Try/Catch once the endpoint is meant for real traffic.

A typical request lifecycle

Most REST endpoints follow the same shape, just with different nodes in between:

• • API Endpoint — receives the request.
• • Validation — checks the request body against a schema, before anything touches your data.
• • Auth (optional) — verifies the caller, see Authentication.
• • SQL / Database — reads or writes data, see Database.
• • Transform — shapes the data for the response, hiding internal fields the caller shouldn't see.
• • Response — sends it back.

Order matters: put Validation and Auth as early as possible in the chain, so a bad or unauthorized request never reaches your database at all. You can test the whole chain from the builder before exporting — see Execution.

Limitations

• • One API Endpoint node handles one method + path combination — two methods on the same path (e.g. GET and POST /orders) need two separate nodes, not one shared node with branching logic.
• • There's no built-in request size limit configurable per endpoint yet — enforce one explicitly with a Validation node if you need to reject oversized bodies.

From canvas to real routes

When you export your backend, every API Endpoint node becomes a real route in the framework you chose — Hono, Express, Fastify, Elysia or FastAPI — with the same method, path and logic you designed on the canvas. Nothing is reinterpreted at deploy time; the generated code is what runs. See Framework Export.