Generic access to every CLIP v2 resource type.

Nothing in this library is a special case of anything else: light, room, scene, behavior_instance, and the thirty-odd others all go through here, so no consumer is ever blocked by a missing wrapper.

{:ok, lights} = Hue.Resource.list(client, :light)
:ok = Hue.Resource.update(client, :light, rid, %{"on" => %{"on" => true}})

Partial success

A bridge response can carry both data and errors — some of what you asked for worked. Pass return: :detailed to receive {:ok, data, errors} instead of having the errors discarded. get/4 does not accept it: it already unwraps to a single resource, and there is no data list left for the errors to sit alongside.

Writes

update/5 and delete/4 return plain :ok in the default :simple mode. The bridge answers a write with only the rid it touched, which carries no information the caller did not already have — the actual state change arrives on the eventstream, not in this response.

Telemetry

Every call is wrapped in :telemetry.span/3 under [:hue, :request], so [:hue, :request, :start] and either [:hue, :request, :stop] or [:hue, :request, :exception] fire around it. Start metadata carries :method and :path; stop metadata adds :result (:ok or :error), reflecting what the caller receives — including a domain-level reinterpretation such as get/4 collapsing an empty result to :not_found, not just the wire-level HTTP outcome.

Trust boundary

type and rid are interpolated straight into the request path with no escaping. A rid from a less-trusted source could contain something like ../ and redirect the request elsewhere on the same bridge. The blast radius is bounded by whatever the application key itself can reach — this is not a privilege escalation — but rids are expected to come from the bridge (a prior list/3, get/4, or create/4 response), not from end-user input passed straight through.