Summary

Every public method in CSAPIQueryBuilder — including per-ID methods like getDataStream(id), getDataStreamSchema(id), and getControlStream(id) — calls assertResourceAvailable() before constructing the URL. This guard throws EndpointError if the resource type was not discovered as a top-level link during builder construction, even when the caller already has a valid resource ID and the URL pattern is completely deterministic.

This makes the URL builder unusable for Part 2 resources (datastreams, observations, controlStreams, commands) on servers that only advertise these types as nested paths under systems — which is the common case for OGC Connected Systems servers.

Observed Behavior

Server: OpenSensorHub at http://45.55.99.236:8080/sensorhub/api

The OSH server advertises datastreams only as nested links under /systems/{id}/datastreams, not as a top-level /datastreams endpoint. During builder construction, scanCsapiLinks() does not find datastreams as a top-level link, so availableResources does not include it.

// ❌ Throws EndpointError even though the URL would be perfectly valid:
builder.getDataStreamSchema('03tbj7mvqg50')
// EndpointError: Collection 'csapi-explorer' does not support 'datastreams' resource.
//   Available resources: systems, deployments, procedures, samplingFeatures, properties

// The URL it WOULD construct is completely valid:
// → /datastreams/03tbj7mvqg50/schema   ← works fine when fetched directly

Root Cause

assertResourceAvailable() conflates two distinct concerns:

1. "Can I list all resources of this type?" — Requires a top-level collection endpoint. Guard is appropriate.
2. "Can I construct a URL for a specific resource by ID?" — The URL is deterministic from type + ID. Guard is inappropriate.

Scope of Impact

Of the 87 methods (updated count) that call assertResourceAvailable():

• 15 are collection/list methods (no ID parameter) — guard is reasonable
• 72 are per-ID methods — guard is overly strict