ifURI

Registry i bindings

urirun oddziela kontrakt pakietu (bindings) od drzewa wykonania (registry). Dzięki temu te same adresy URI działają w shellu, backendzie, flow i w aplikacji IFURI.

Dokument bindingów

Przenośny JSON: opisuje trasy URI, schematy wejścia (JSON Schema) i konfigurację adaptera.

{
  "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

Registry kompiluje się z jednego lub wielu dokumentów bindingów:

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

Runtime dispatchuje wyłącznie z registry. To czyni wygenerowany rejestr łatwym do przeglądu, odtwarzalnym i bezpiecznym do przekazania między klientami shell, usługami HTTP, konsolą w przeglądarce, orkiestratorami Docker i flow IFURI.

Tożsamość trasy

Liczy się pełny URI. Trasa:

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

może współistnieć z:

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

ponieważ target jest częścią tożsamości trasy. To unika konfliktów, gdy wiele usług w LAN wystawia ten sam kształt operacji dla różnych urządzeń/węzłów.

Polityka konfliktów