Research in support of the SQL-on-FHIR $materialize operation design (issue #326). Question: how does the industry (a) create / refresh / drop materializations, and (b) let clients control acceptable data staleness? Sourced from official documentation (links at the bottom).
The current $materialize proposal uses 3 HTTP verbs on one URL (POST = create-or-refresh idempotently, GET = status, DELETE = drop), an async poll pattern, a parameter expressing acceptable staleness (working name freshnessTarget / maxAge, a Duration; absent = manual, 0 = always-live, PT5M = lag ≤ 5 min, server may accept or reject), and a validAsOf output reporting actual freshness.