FlowDrop Workflow Specification 1.0-draft

A client-supplied id never overwrites an existing workflow

The rule

Normative: this is the rule
  1. A create request may supply the workflow's id.
  2. If a workflow with that id already exists, the request is refused with 409 and the stored workflow is left exactly as it was.
  3. An implementation must never silently turn a create into an update.

What it means

A caller may name the id it wants a new workflow to have, rather than being handed one. That is a convenience with one sharp edge: an id is also how an existing workflow is addressed, so a create request naming an id already in use is ambiguous between "make this" and "replace that". The rule resolves the ambiguity in one direction only — it is never an update. The incumbent workflow is left exactly as it was, and the request that collided is refused.

Example

The same id, sent as a create twice.

A new id201 — stored
POST /api/flowdrop/workflows

{"id": "taken", "name": "The incumbent"}
The same id, claimed again409 — refused
POST /api/flowdrop/workflows

{"id": "taken", "name": "The impostor"}

The second request never reaches the workflow named taken; the incumbent keeps its own name.

Rule identifiers are permanent and are never renumbered. Each implementation publishes its own standing against these rules; this specification does not.spec 1.0-draft · STORE-3 · changed in spec 1.0