Parent Issue

Split from #100 — assertResourceAvailable() is overly strict for per-ID methods — blocks valid URL construction for nested resources.

This is Part 1 of 2. See also: Part 2 (remaining resource types — issue to follow).

Scope — Part 1 Only

Remove this.assertResourceAvailable(...) from per-ID methods for the first 4 resource types. These are the Part 1 resources that typically ARE advertised as top-level links, but per-ID methods should still not guard on collection-level discovery.

Resource Types in This Part

File to Modify

Pattern

Each per-ID method changes from:

getSystem(id: string, options?: QueryOptions): string {
  this.assertResourceAvailable('systems');  // ← Remove this line
  return this.buildResourceUrl('systems', id, undefined, options);
}

to:

getSystem(id: string, options?: QueryOptions): string {
  return this.buildResourceUrl('systems', id, undefined, options);
}

Which Methods to Change (33 deletions)

Systems (14): All methods matching get/update/deleteSystem* that take an id parameter. Examples: getSystem(), updateSystem(), deleteSystem(), getSystemDataStreams(), getSystemControlStreams(), getSystemDeployments(), getSystemSamplingFeatures(), getSystemProcedure(), getSystemHistory(), etc.

Deployments (7): All methods matching get/update/deleteDeployment* that take an id parameter. Examples: getDeployment(), updateDeployment(), deleteDeployment(), getDeploymentSubdeployments(), getDeploymentSystems(), etc.

Procedures (6): All methods matching get/update/deleteProcedure* that take an id parameter. Examples: getProcedure(), updateProcedure(), deleteProcedure(), getProcedureSystems(), getProcedureDataStreams(), etc.

SamplingFeatures (6): All methods matching get/update/deleteSamplingFeature* that take an id parameter. Examples: getSamplingFeature(), updateSamplingFeature(), deleteSamplingFeature(), getSamplingFeatureSystems(), etc.

Which Methods to KEEP Unchanged

All list/create methods (no id parameter) retain their assertResourceAvailable() guard:

• getSystems(), createSystem(), getDeployments(), createDeployment(), getProcedures(), createProcedure(), getSamplingFeatures(), createSamplingFeature()

The guard is appropriate for these because listing a collection requires that the server actually advertises a top-level endpoint for it.

What NOT to Touch

• ❌ Properties, Datastreams, Observations, ControlStreams, Commands — those are Part 2
• ❌ List/create methods (no id parameter) — keep their guards
• ❌ assertResourceAvailable() definition itself — leave it intact for list/create use
• ❌ buildResourceUrl() — no changes needed, it already handles fallback paths
• ❌ Any file outside url_builder.ts
• ❌ Test files — existing tests should pass unchanged (the guard removal makes previously-throwing paths succeed)

Acceptance Criteria (Part 1)

• 33 this.assertResourceAvailable(...) calls removed from per-ID methods for Systems, Deployments, Procedures, SamplingFeatures
• 8 list/create methods for these 4 types still have their assertResourceAvailable() guards
• tsc --noEmit — zero errors
• npm test — all tests pass
• npm run lint — zero errors

Dependencies

Blocked by: Nothing
Blocks: Part 2, #145 (build() wrapper), #102 (nested parent IDs)

References

• [SPLIT] assertResourceAvailable() overly strict for per-ID methods → #156 + #157 #100 — parent issue with full analysis, cross-server findings, OGC spec context
• CSAPIQueryBuilder.assertResourceAvailable(): url_builder.ts ~L320–327
• buildResourceUrl() fallback behavior: url_builder.ts ~L256–273
• Phase 7 Scope & Split Assessment

Operational Constraints

⚠️ MANDATORY: Before starting work on this issue, review docs/governance/AI_OPERATIONAL_CONSTRAINTS.md.

Upstream Isolation Constraint

Per the upstream maintainer's comment on PR #136: url_builder.ts is within src/ogc-api/csapi/ — purely internal to the isolated CSAPI module.