proposal

RESTful resources

This is a proposal. It shows how conventional REST falls out of the proposed engine as the zero-config default - nothing new to learn for the common case.

Conventions as defaults, not rules

When you don't say otherwise, Akuma infers the operation from the method and path, exactly as a REST reader would expect:

Method + pathInferred operation
GET /userslist
GET /users/:idget
POST /userscreate
PATCH/PUT /users/:idupdate
DELETE /users/:iddelete

A full resource, terse

schemas:
  User:
    properties:
      id: number
      name: string
      email: string

endpoints:
  - { path: /users,     method: GET,    response: { type: array, schema: User } }
  - { path: /users/:id, method: GET,    response: { schema: User } }
  - { path: /users,     method: POST,   response: { schema: User }, status: 201 }
  - { path: /users/:id, method: PATCH,  response: { schema: User } }
  - { path: /users/:id, method: DELETE, response: { schema: User }, status: 204 }

No operation: and no key: appear - they're inferred. This is the same surface Akuma serves today, now expressed on the general engine.

Non-integer ids, still RESTful

REST doesn't require integer ids. Because the key column defaults to the path-parameter name and binds as text, UUID- or slug-keyed resources need no extra config:

- { path: /users/:guid,  method: GET, response: { schema: User } }   # WHERE guid = :guid
- { path: /posts/:slug,  method: GET, response: { schema: Post } }   # WHERE slug = :slug

Open questions