ifURI

Registry & bindings

urirun separates the package contract (bindings) from the execution tree (registry). The same URI addresses then work in a shell, a backend, a flow and the IFURI app.

Binding document

Portable JSON: it describes URI routes, input schemas (JSON Schema) and adapter configuration.

{
  "version": "urirun.bindings.v2",
  "bindings": {
    "report://local/render/pdf": {
      "kind": "command",
      "adapter": "argv-template",
      "inputSchema": {
        "type": "object",
        "required": ["input", "output"],
        "properties": {
          "input": { "type": "string" },
          "output": { "type": "string" }
        },
        "additionalProperties": false
      },
      "argv": ["python3", "render.py", "{input}", "{output}"]
    }
  }
}

Registry

The registry is compiled from one or more binding documents:

urirun compile bindings.v2.json --out registry.json

The runtime dispatches from the registry only. That makes a generated registry reviewable, reproducible and safe to pass between shell clients, HTTP services, browser consoles, Docker orchestrators and IFURI flows.

Route identity

The full URI matters. A route:

device://device-01/led/command/set

can coexist with:

device://device-02/led/command/set

because the target is part of the route identity. This avoids conflicts when several LAN services expose the same operation shape for different devices/nodes.

Conflict policy